Protected should definitely be the exception not the rule. Always prefer private over protected. A lot of protected methods usually means your inheritance hierarchy likely needs some tuning. In all of the classes I have written in the last ten years I have probably used protected in about 1% of them. Private in a base class communicates that the designer is saying the derived class should not need access to the method or variable and if they do...then there is a problem with the design of the derived class. If the client has access to the code they would have to change the private to protected to gain access to it. This alone would trigger a red flag in their head that perhaps they should not be mucking around with the original base classes.
In some instances protected methods are needed such as when the base class is providing some core functionality that it only wants to expose to derived classes. But since I normally derive from interfaces (read pure virtual or abstract base classes) and I rarely, if ever, derive from a concrete class I almost never have a need to use protected. Also this core functionality could just as easily be exposed via a design pattern like flyweight. I would agree with CornedBee in that there should never be any protected member variables. The only time I would ever use any public member variables is if profiling indicated that access to variables was significantly impacted. Even then I would vomit in the back of my throat if I made any variables public. As well if I worked in a studio with more than a few developers touching the same code I would prepare myself for the eventual firestorm that would be headed my way due to my class that had public variables. I have debugged code that did this and wow what a mess. This class poking around inside that class which pokes around inside another class which alters the value which another class uses and then pokes around in another class....you can barely find out who or what is changing the variable that is causing the code to crash. A huge nightmare. I will step out on a limb here and say that if you make member variables public in an existing code line for any reason at all you will create a firestorm later that could put the code line in a potentially unusable or unmaintainable state.
