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.
I hope you enjoyed this journey and learned something new. If you want to stay updated with my latest thoughts and ideas, feel free to register for my newsletter. You can also find me on LinkedIn or Twitter. Let's stay connected and keep the conversation going!
Top comments (0)