Private vs Protected
Posted by Uncle Bob on 01/21/2007
Someone on comp.object recently asked why anyone would make a field private since privacy ruins extensibility.
I recently read an article on comp.object that asked the following question:
While I can see that the ‘private’ modifier has its uses, I’m puzzled as to why it’s advocated so much given that one of the strong points of OO is extensibility.
I responded with:
The Open-Closed Principle of OOD (See article) says that objects should be open for extension but closed for modification. In other words, you should be able to change what a module does without changing the module. Extensibility, in OO, is best achieved when you keep the code you are extending safe from modification.
How do you protect a module from the forces that would try to modify it? One technique is to keep the variables that module depends upon private. If a variable is not private, then it is open to be used in a way that the module that owns that variable does not intend. Indeed, using a variable in an unintended way is the only reason to make the variable public or protected. But when you use a variable in an unintended way you likely force modifications into the owner. If, on the other hand, all the variables of a module are private, then no modification can be caused through unintended useage.
Privacy does not preclude extensibility. You can create public or protected accessor methods that: 1) provide extenders access to certain variables, and 2) ensure that the extenders don’t use the variable in an unintended way.
For example, given a variable v used by a module m, such that v should never be negative. If you make v public or protected someone could set it to a negative number breaking the code in m and possibly forcing mofidication to m. However, if v is private but is accessible through getV and setV methods; and if the setV method throws an exception if you pass it a negative number, then m is safe, and extenders are forced to follow the rules that m expects.
To be fair, while I am a big proponent of keeping variables private, I have also come to rely much more on my unit tests to enforce the appropriate use of variables. When the code enjoys 90+% unit test coverage those tests will uncover and prevent variable misuse. This softens the need for the compiler to enforce privacy. This is not to say that you should not make your variables private, you should. It is to say that if you use TDD, the cost/benefit ratio changes, and you may find that you can soften access to some variables.
Comments
belugabob 1 day later:
“When the code enjoys 90+% unit test coverage those tests will uncover and prevent variable misuse.”
...providing, of course, that you’re not shipping your code as an API, in which case you can’t predict what the users of the API will do.
eirikm 3 days later:
Funny thing then that Eiffel doesn’t have a ‘private’ modifier (not the last time I checked, that is). AFAIK, The Open-Closed Principle was first mentioned in Object-Oriented Software Construction by Dr. Bertrand Meyer, who incidentally is the designer of Eiffel.
Eiffel over 3 years later:
Eiffel doesn’t have a “private” modifier because all Eiffel fields are “private”:http://en.wikipedia.org/wiki/Eiffel_(programming_language)#Scoping
Ray Cruz over 4 years later:
At the very first, I’d choose to give thanks to you for this informative article. Second, I had prefer to doubt wherever I can find lot more information related to your article. I arrived here via Bing & can’t distinguish any linked up web websites along this matter. How do I subscribe for your web blog? I’d prefer to stick to your updates as they come along! I’d a query to interrogate but I forgotten what it absolutely was… anyways, thanx. Author of how to cook beef tenderloin
XoX, Ray Cruz
bag manufacturer over 4 years later:
ul, but also very bizarre. If you aren’t careful you can get algorithms that work
Regim Hotelier over 4 years later:
I’m in the process of learning oop and classes in c++ and one thing I’m trying to grasp is when you write a class when it Protected preferred over using private? Can someone explain this to me, I just cannot understand why one would be better than the other, and why not just use private?
Thanks for any info.
virtuemart templates over 4 years later:
when you write a class when it Protected preferred over using private? Can someone explain this to me, I just cannot understand why one would be better than the other, and why not just use private virtuemart templates
Criminal Check over 4 years later:
It is to say that if you use TDD, the cost/benefit ratio changes, and you may find that you can soften access to some variables.
Criminal Records over 4 years later:
To be fair, while I am a big proponent of keeping variables private, I have also come to rely much more on my unit tests to enforce the appropriate use of variables. When the code enjoys 90+% unit test coverage those tests will uncover and prevent variable misuse. This softens the need for the compiler to enforce privacy. This is not to say that you should not make your variables private, you should.
Tenant Screening over 4 years later:
If a variable is not private, then it is open to be used in a way that the module that owns that variable does not intend. Indeed, using a variable in an unintended way is the only reason to make the variable public or protected.
okey oyunu oyna over 4 years later:
“Privacy does not preclude extensibility. You can create public or protected accessor methods that: 1) provide extenders access to certain variables, and 2) ensure that the extenders don’t use the variable in an unintended way “
i agree with it …
Dünyan?n en büyük online okey oyunu bu sitede sizleri bekliyor. Gerçek ki?ilerle sohbet ederek Okey Oyunu Oyna ve internette online oyun oynaman?n zevkini ç?kar
provide extenders access to certain variables, and 2) ensure that the extenders don’t use the variable in an unintended way cheap beats by dre beats by dre store