Kotlin Code Smell 27 - Protected Attributes
SOLID Solutions: Beyond Sub-Classification Struggles
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
Problem
- Sub-classification for code reuse purposes.
- Liskov substitution violation (SOLID principle).
- Possible subclass overrides.
Solution
- Favor composition
- Avoid subclassifying attributes.
- Extract behavior to separate objects.
Sample Code
Wrong
abstract class ElectronicDevice(protected val battery: Battery)
abstract class IDevice(
battery: Battery,
protected val operatingSystem: OperatingSystem
) : ElectronicDevice(battery)
class IPad(
battery: Battery,
ios: OperatingSystem
) : IDevice(battery, ios)
class IPhone(
battery: Battery,
ios: OperatingSystem,
val phoneModule: PhoneModule
) : IDevice(battery, ios)
Right
interface ElectronicDevice {
//...
}
interface PhoneCommunication {
//...
}
class IPad(
private val battery: Battery,
private val operatingSystem: OperatingSystem
) : ElectronicDevice {
// Implement iPad-specific functionality here
}
class IPhone(
private val battery: Battery,
private val operatingSystem: OperatingSystem,
private val phoneModule: PhoneModule
) : ElectronicDevice, PhoneCommunication {
// Implement iPhone-specific functionality here
}
Conclusion
Protected attributes are yet another tool we should use carefully. Every decision is a smell, and we should be very cautious with attributes and inheritance.
