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?”
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.