Software Engineering
code-quality clean-code variables
Updated Mon, 13 Jun 2022 15:15:42 GMT

Why is Clean Code suggesting avoiding protected variables?


Clean Code suggests avoiding protected variables in the "Vertical Distance" section of the "Formatting" chapter:

Concepts that are closely related should be kept vertically close to each other. Clearly this rule doesn't work for concepts that belong in separate files. But then closely related concepts should not be separated into different files unless you have a very good reason. Indeed, this is one of the reasons that protected variables should be avoided.

What is the reasoning?

Solution

Protected variables should be avoided because:

  1. They tend to lead to YAGNI issues. Unless you have a descendant class that actually does stuff with the protected member, make it private.
  2. They tend to lead to LSP issues. Protected variables generally have some intrinsic invariance associated with them (or else they'd be public). Inheritors then need to maintain those properties, which people can screw up or willfully violate.
  3. They tend to violate OCP. If the base class makes too many assumptions about the protected member, or the inheritor is too flexible with the behavior of the class, it can lead to the base class' behavior being modified by that extension.
  4. They tend to lead to inheritance for extension rather than composition. This tends to lead to tighter coupling, more violations of SRP, more difficult testing, and a slew of other things that fall within the 'favor composition over inheritance' discussion.

But as you see, all of these are 'tend to'. Sometimes a protected member is the most elegant solution. And protected functions tend to have fewer of these issues. But there are a number of things that cause them to be treated with care. With anything that requires that sort of care, people will make mistakes and in the programming world that means bugs and design problems.

Comments (5)

  • +0 – Thanks for many good reasons. However, the book mentions it specifically in a context of formatting and vertical distance, it's that part I'm wondering about. — Aug 28, 2012 at 16:12  
  • +2 – It seems that Uncle Bob is referring to vertical distance when someone is referring to a protected member between classes, and not in the same class. — Aug 28, 2012 at 16:18  
  • +5 – @Matsemann - sure. If I remember the book accurately, that section focuses on the readability and discover-ability of code. If variables and functions work on a concept they should be close in code. Protected members will be used by derived types, which necessarily cannot be close to the protected member since they're in a completely different file. — Aug 28, 2012 at 16:32  
  • +2 – @steve314 I can't imagine a scenario where the base class and all of its inheritors will only ever live in one file. Without an example I am inclined to think it an abuse of inheritance or poor abstraction. — Aug 28, 2012 at 22:08  
  • +4 – YAGNI=You Aint Gonna Need it LSP=Liskov Substitution Principle OCP=Open/Close Principle SRP=Single Responsibility Principle — Dec 11, 2013 at 01:48  

External Links

External links referenced by this document:

References