Protected attributes are great for encapsulating and controlling access to our properties. They might be warning us for another smell.
Problems
Sub classification for code reuse purposes.
Liskov substitution violation (SOLID principle).
Possible subclass overrides.
Solutions
- Favor composition
- Don't subclassify attributes.
- Extract behavior to separate objects.
- Use [traits](https://en.wikipedia.org/wiki/Trait_(computer_programming) (if available).
Wrong
Right
Detection
In languages supporting protected attributes we can avoid them by policy or have a warning of this smell.
Tags
- Encapsulation
Conclusion
Protected attributes are yet another tool we should use carefully. Every decision is a smell, and we should be very careful with attributes and inheritance.
Relations

Code Smell 11 - Subclassification for Code Reuse
Maxi Contieri ・ Oct 30 '20 ・ 1 min read
More Info
Credits
Photo by Jonathan Farber on Unsplash
Subclasses shouldn’t always share all characteristics of their parent class but will do so with inheritance. This can make a program’s design less flexible. It also introduces the possibility of calling methods on subclasses that don’t make sense or that cause errors because the methods don’t apply to the subclass.
Steve Klabnik
Discussion (1)
Loving the series!