Sometimes we need to create an object of a slight modification of some class, without explicitly declaring a new subclass for it. Java handles this case with anonymous inner classes. Kotlin slightly generalizes this concept with object expressions and object declarations.
Object expressions
To create an object of an anonymous class that inherits from some type (or types), one writes:
window.addMouseListener(object : MouseAdapter() { override fun mouseClicked(e : MouseEvent) { // ... } override fun mouseEntered(e : MouseEvent) { // ... } })If a supertype has a constructor, appropriate constructor parameters must be passed to it. Many supertypes may be specified as a comma-separated list after the colon:
open class A(x : Int) { public open val y : Int = x } trait B {...} val ab = object : A(1), B { override val y = 15 }If, by any chance, we need "just an object", with no nontrivial supertypes, we can simply say:
val adHoc = object { var x : Int = 0 var y : Int = 0 } print(adHoc.x + adHoc.y)Object declarations
Singleton is a very useful pattern, and Kotlin (after Scala) makes it easy to declare singletons:
object DataProviderManager { fun registerDataProvider(provider : DataProvider) { // ... } val allDataProviders : Collection<DataProvider> get() = // ... }This is called an object declaration. If there's a name following the object keyword, we are not talking about an expression any more. We cannot assign such a thing to a variable, but we can refer to it by its name. Such objects can have supertypes:
object DefaultListener : MouseAdapter() { override fun mouseClicked(e : MouseEvent) { // ... } override fun mouseEntered(e : MouseEvent) { // ... } }Semantical difference between object expressions and declarations
There is one important semantical difference between object expressions and object declarations:
- object declarations are initialized lazily, when accessed for the first time
- object expressions are executed (and initialized) immediately, where they are used

9 Comments
comments.show.hideJul 21, 2011
Anonymous
window.addMouseListener(object:MouseAdapter(){
Unmatched parentheses.
Jul 25, 2011
Anonymous
Actually no, the matching parentheses for the call to addMouseListeneris on the last line of the exemple, just after the closing curly brace of the object expression under demonstration.
As denoted by the empty constructor call "()", the "object:MouseAdapter()" part is an inheritance specification, not a type declaration, and is followed by the object specification proper, between curly braces.
Maybe it would actually be better to distinguish between type declarations and inheritance specifications, for example by adopting the conventional "<:" subtype operator for the latter. It would also allow to drop the empty constructor call.
Jul 25, 2011
Anonymous
I don't know if you should be so enthusiastic about the singleton pattern, even if Scala embraced it.
After all, even according to the very Wikipedia page you linked too, the use of this pattern has become quite controversial, and the industry, especially its testing side, seems to be moving away from it.
Aug 12, 2011
Alex Tkachman
I am not sure that use of the same keyword 'object' both for singleton and anonymous inner class is a good idea. Someone can expect that instance of inner class will be singleton as well
Aug 12, 2011
Maxim Shafirov
Fair. For now we aren't sure we need object declarations at all
Feb 20, 2012
Boris Okunskiy
I personally think that singletons are important. On the one side, heavy use of singletons makes an application hard to extend, that's why they can actually be deprecated in libraries. But when it comes down to the end-application, their use is ubiquitous. Just consider tables, lightweight configuration objects, repositories, threadlocal-helpers, etc, etc, etc.
Rephrasing Voltaire, if there were no singletons, it would've been necessary to invent them.
Jul 12, 2012
Matt Gile
I really appreciate the idea of adhoc classes, a small class (more structure) I use inside of a complicated method. Currently we uses anonymous inner class often and would benefit from being able to implement many interfaces.
Kind of related to this is Scala "with" operator, where an object can have a trait attached to it (an instantiated object). This almost feels like meta programming.
Dec 30, 2012
Daniel Ferreira Monteiro Alves
There is no way to get back secondary constructors? Apparently they are not necessary, but in some cases, usually when working with some frameworks... it is needed.
An example is when I need to create an immutable type. The hibernate needs a default constructor but I need to force the developer of the API to set the values at the object's construction.
I can not create that in Kotlin, at least I don't know how! I can create that in Scala, but the accessors are strange and does not generate a pair of get / set methods, necessary for the most frameworks.
Jan 09, 2013
Andrey Breslav
Why not use a factory method?