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?
Related: "Why do we need private variables?"
Answer: The Issues (135 Votes)
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.
Answer: Specifically… (13 Votes)
I haven't read the book, but I can take a stab at what Uncle Bob meant.
If you put protected on something, that means that a class can inherit it. But member variables are supposed to belong to the class in which they are contained; this is part of basic encapsulation. Putting protected on a member variable breaks encapsulation because now a derived class has access to the implementation details of the base class. It's the same problem that occurs when you make a variable public on an ordinary class.
To correct the problem, you can encapsulate the variable in a protected property, like so:
protected string Name
{
get { return name; }
private set { name = value; }
}
This allows name to be safely set from a derived class using a constructor argument, without exposing implementation details of the base class.
Related: "Where to declare variables?"
Answer: Avoid the Hunt (7 Votes)
Uncle Bob's argument is primarily one of distance: if you have a concept that is important to a class, bundle the concept together with the class in that file. Not separated across two files on the disk.
Protected member variables are scattered in two places, and, kinda looks like magic. You reference this variable, yet it isn't defined here... where is it defined? And thus the hunt begins. Better to avoid protected altogether, his argument goes.
Now I don't believe that rule needs to be obeyed to the letter all the time (like: thou shalt not use protected). Look at the spirit of what he is getting at... bundle related things together into one file—use programming techniques and features to do that. I would recommend that you don't over-analyze and get caught up in the details on this.
Think you know why it's best to avoid protected variables? Disagree with the opinions expressed above? Bring your expertise to the question at Stack Exchange, a network of 80+ sites where you can trade expert knowledge on topics like web apps, cycling, patents, and (almost) everything in between.
reader comments
25