Problem

• Sub-classification for code reuse purposes.
• Liskov substitution violation (SOLID principle).
• Possible subclass overrides.

Solution

1. Favor composition
2. Avoid subclassifying attributes.
3. 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.

Credits

• Code Smell 37 - Protected Attributes by Maximiliano Contieri