Kotlin Code Smell 9 - Subclassification for Code Reuse
Crafting Flexible Code: The Power of Composition Over Inheritance
I've started to work as a software engineer at 2014, however, I started to write code at high-school.
My first language was Assembly, but still, I fall in love with the possibilities to make the computer to do as you wish, shortly after that I started to write in C.
Later on I studied a practical engineering in electricity, and during this time discovered that I preferred much more writing code than design electrical components.
As a result of this understanding I decided to switch and study bachelor degree in computer science in Reichman university, where the focus was of the Java language.
Today I'm working at SumUp using Kotlin, SpringBoot & Micronaut, Cassandra and Kafka
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)
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()
}
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.
