Inheritance is bad… Everyone knows it, but why?

1. What is inheritance?

It’s a way for classes to ‘inherit’ all properties from another class. We usually say that the class we inherit is called a superclass, and the class that inherits properties is called a subclass.

In Kotlin, there’s Single Inheritance only, meaning there’ll always be a single subclass and a single superclass. In Kotlin, we can use it in two ways:

  1. With open class
// With open classes
open class Cat {
fun meow() {
println("meow")
}
}
class SpecificCat : Cat() {
fun specificFunction() {
println("specific")
}
}
fun main() {
val cat = Cat()
cat.meow() // meow
val specificCat = SpecificCat()
specificCat.meow() // meow
specificCat.specificFunction() // specific
}

2. With abstract class

abstract class Cat {
fun meow() {
println("meow")
}
abstract fun specificFunction()
}
class SpecificCat : Cat() {
override fun specificFunction() {
println("specific")
}
}
fun main() {
// Creating Cat throws compilation error
// we can't create abstract classes
// val cat = Cat()
val specificCat = SpecificCat()
specificCat.meow() // meow
specificCat.specificFunction() // specific
}

Not that we would try to make SpecificCat inherit from two classes, it’s impossible:

open class WalkingCat {
fun walk() {
println("walk")
}
}
// Compilation error: Only one class may appear in a supertype list
class SpecificCat : Cat(), WalkingCat() {
override fun specificFunction() {
println("specific")
}
}

These are the main limitations:

  • We can only inherit from a single class.
  • We take everything from that class, even things we don’t need.
  • It’s harder to read, especially when working with multiple levels of inheritance. SpecificCat could inherit from Cat and then SpecificWalkingCat could inherit from SpecificCat while using methods defined in Cat class. It’s hard to navigate and understand that type of code.

2. What is Composition?

It’s a principle that classes should have ‘has a’ relationships. This way, we can divide and ‘compose’ the properties we class should have. It’s done through Interface s and classes that implement them.

We could refactor the Inheritance example to use composition:

interface Mouth {
fun speak()
}
class CatMouth : Mouth {
override fun speak() {
println("meow")
}
}
class SpecificCat {
private val mouth: Mouth = CatMouth()
fun meow() {
mouth.speak()
}
fun specificFunction() {
println("specific")
}
}
fun main() {
val specificCat = SpecificCat()
specificCat.meow() // meow
specificCat.specificFunction() // specific
}

Or, even better, by using Kotlin delegates, we’re able to add all the Mouth functions to SpecificCat :

class SpecificCat : Mouth by CatMouth() {
fun specificFunction() {
println("specific")
}
}
fun main() {
val specificCat = SpecificCat()
// Now we use 'speak' because meow was removed
specificCat.speak() // meow
specificCat.specificFunction() // specific
}

The main benefits of using composition are:

  • Reusability — you can reuse the implementation of an interface in multiple classes.
  • ‘has a’ relationship — you can have multiple properties and compose code more readably.
  • You control what is visible to the outside world and what is not!
  • You can leverage Kotlin Delegates to add all properties from the implementing class without the drawbacks of inheritance.

If you’ve learned something new please clap and follow me for more!

Source link