DEV Community

Yonatan Karp-Rudin
Yonatan Karp-Rudin

Posted on • Originally published at yonatankarp.com on

Kotlin Code Smell 9 - Subclassification for Code Reuse

TL;DR: Always favor composition over inheritance.

Problems

  • Coupling

  • Maintainability

Solutions

  • Composition

Exceptions

  • If the hierarchy follows the principle of "behaves like," then it is safe.

Sample Code

Wrong

open class Rectangle(
    protected val length: Int,
    protected val width: Int
) {
    open fun area() = length * width
}

class Square(size: Int) : Rectangle(size, size) {
    override fun area() = length * length
}

class Box(size: Int) : Rectangle(size, size)
Enter fullscreen mode Exit fullscreen mode

Right

interface Shape {
    fun area(): Int
}

class Rectangle(
    private val length: Int,
    private val width: Int
) : Shape {
    override fun area() = length * width
}

class Square(private val size: Int) : Shape {
    override fun area() = size * size
}

class Box(size: Int) {
    private val shape: Square

    init {
        shape = Square(size)
    }

    fun area() = shape.area()
}
Enter fullscreen mode Exit fullscreen mode

Conclusion

In legacy systems, it is common to have deep hierarchies and method overriding. However, it is important to refactor them and subclass them for essential reasons rather than implementation reasons.


Stay updated with my latest thoughts and ideas by registering for my newsletter. Connect with me on LinkedIn or Twitter. Let's stay connected and keep the conversation going!


More info

Credits

Top comments (0)