Composition over inheritance (and Kotlin)

Composition over inheritance is the principle that classes should achieve polymorphic behavior and code reuse by their composition (by containing instances of other classes that implement the desired functionality) rather than inheritance from a base or parent class.

- Wikipedia

In computer science classes you get to learn a ton about inheritance. You study the different programming languages and how they implement inheritance (or multiple inheritance) in the name of polymorphism.

A simple inheritance example is having a base/parent class that many more classes are extending, potentially for more than one level:

open class Parent {
    fun parentFunctionality() {}
}

open class Child(): Parent() {
    fun childFunctionality() {}
}

class Grandchild constructor() : Child() {
    fun grandchildFunctionality() {}
}

An instance of Grandchild will be able to use childFunctionality() and parentFunctionality()

But in real-world software engineering, inheritance is not that desirable. There's even a software engineering principle against inheritance!

The example above would look like this using composition:

open class Parent {
    fun parentFunctionality() {}
}

open class Child() {
    private val parent = Parent()
    
    fun parentFunctionality() { parent.parentFunctionality() }
    fun childFunctionality() {}
}

class Grandchild  {
    private val parent = Parent()
    private val child = Child()

    fun parentFunctionality() { parent.parentFunctionality() }
    fun childFunctionality() { child.childFunctionality() }
    fun grandchildFunctionality() {}
}

But why follow this pattern when it's more verbose? And when should someone prefer composition over inheritance? Should we avoid it at all times?

There are plenty of advantages for going with composition:

• Testability : You just swipe the real implementation with the fake one. Especially convenient with a dependency injection framework.
• Maintainability : Multilevel inheritance can make the code hard to read and comprehend, especially for people unfamiliar with the codebase. Composition is simpler, but maybe a bit more verbose.

Kotlinprovides some feature to make composition easier:

• Objects : Essentially they are singleton values defined with their own keyword. The first time they are used an instance will be created and all the following invocations will use the same (single) instance. Especially useful if you do not use a dependency injection framework and you need singleton instances around your app.

object Parent {
    fun parentFunctionality() {}
}

object Child {
    private val parent = Parent
  
	[...]
	fun childFunctionality() {}
}

object Grandchild  {
    private val parent = Parent
    private val child = Child 
    
	[...]
	fun grandchildFunctionality() {}
}

• Lazy : Useful if you want an instance only the first time a property is used. All the following invocations will use the instance that was created the first time.

open class Parent {
    fun parentFunctionality() {}
}

open class Child() {
    val parent by lazy { Parent() }

	[...]
    fun childFunctionality() {}
}

class Grandchild {
    val parent by lazy { Parent() }
    val child by lazy { Child() }

	[...]
    fun grandchildFunctionality() {}
}

• Extension methods : Not exactly composition, but can be used in the place of inheritance. This is for "virtually" extending a class, even if it's not allowed (e.g. Android system classes).

class SystemClass {
	[...]
}

fun SystemClass.newFunctionality() {}

SystemClass().newFunctionality()

Still, I think there are cases that inheritance should be used instead of composition:

• If you only need 1 level of inheritance, it's easier (and more readable) than composition. When you need more levels, maybe you should switch to composition.
• When you need to implement an interface, you have to use inheritance. The rule that you should try is to implement "interface inheritance", rather the "functional inheritance". Try to "inherit" functionality using composition.

Happy coding with more readable code! (what "readable" means is a discussion for another post :)