Not everything has to be public
Yesterday, Felix Geisendörfer recommended in an article not to use private/protected properties and methods and called them “one of the most stupid concepts of OOP”.
I disagree with him, because visibility is one of the essential concepts of OOP. Let me explain why with a short story.
Max and Moritz both own a coke machine. And both want to make a lot of money with their machines ;-)
Max has a traditional coke machine: its basic functionality is to give you a bottle of coke after you paid for it. And from time to time Max has to replenish the machine with new bottles.
Moritz’ coke machine is slightly different: it doesn’t contain a front cover (it saves him 100 dollar). You just take a bottle of coke and then you can pay for it. And of course it has to be replenished from time to time by Moritz.
After the first day Max is happy about what he earned with his machine. And what about Moritz? He is depressed. His machine is empty. And the cash box too…
If we analyze both machines, we see that Max’ machine is successful because it only gives you access to a bottle when you paid for it.
Or to say it more generally: it is often necessary to restrict the access to something.
It is a concept you find everywhere in the real world. You don’t want that everyone drives with your car, or that everyone can get money from your bank account, and so on.
And so it makes sense to use the same concept in the software engineering world. If I want to model Max’ machine in software, I need a way to show that not everyone can access the bottles. And the same applies at the implementation level. And for this purpose it is essential to be able to distinguish between public and private (plus protected, but it doesn’t fit in the machine metaphor).
At last I want to recommend the opposite to Felix’ recommendation: Make as much as possible private or protected. Not everything has to be public!
I guess it depends on who is accessing your coke machine. If you are the only one drinking the coke then surely it must be easier (and cheaper) just to grab a drink without paying for it!
@Adam Royle but then it wouldn’t be a coke automate but a fridge.
I agree with cakebaker, the semantics is clear when you *correctly* use private, public and protected modifiers. If a developer pretends to go around those modifiers then maybe he/she is the bad programmer.
I agree. The telling points for me is that Felix doesn’t even touch on what I consider the primary benifit of private/protected methods: improved encapsulation and re-usability.
Not that people don’t use private methods and properties incorrectly, but there is very little that can’t be said about. I can’t count the number of times I’ve been asked how to change a session variable from within a view.
@Adam, polerin: Thanks for your comments!
@Adam: Yes, if the requirements are different, you have to build a different machine.
@polerin: Yes, encapsulation and re-usability are important benefits of having private/protected methods.
In addition to not wanting other people to access something, having defined public interfaces will ensure that even a year or two down the road you still won’t rely on dependencies you didn’t think about when writing your object in the first place. You can then replace it with something better, without worrying if somewhere in your project you may have used that method you always thought was not meant to be used by the outside world.
Defining and using clean interfaces is one of the major points dividing hobby hackers from professional software engineers.
Definitely took me a few minutes to figure out what “coke automate” meant! If anyone else is wondering, it means Coke machine. :P
@Frédéric: Thanks for your comment! And yes, interfaces are a powerful concept to make software more flexible.
@Matt: Thanks for the hint, I changed it in the article. It seems “coke automate” is Swiss English ;-)
Hear ye, hear ye!
[...] methods. Debuggable begins by writing a post about not using them and Cakebaker responds with a number of arguments and an example that you do need to use [...]
I am absolutely with you on this one, and as far as I’m concerned, making proper use of public/private and protected methods goes right up there with correctly commenting code, oop evolved to ensure better encapsulation and code re-use for a reason, just as application frameworks such as CakePHP have evolved for much the same reason, by following standards, and conventions, everything becomes much easier to work with, we stop reinventing the wheel, all become more productive and take things forward.
I am a huge fan of debuggable, but this time I think they are way off the mark.
Hi Deniel,
Your idea is almost identical to me. I’ve submitted my comments on Felix’s post and hence not repeating same here. You may have a look at that post at http://debuggable.com/posts/programming-psychology-ii-private-methods:481ed862-b0d8-4a0e-9247-165c4834cda3#comment-4877e9aa-cf90-4cb1-954b-361e4834cda3
You might get more ideas there on this funky false topic.
Regards,
Shihan
@Peter, Shihan: Thanks for your comments!
@Peter: Imho it is good to have such articles from time to time, they force you to think about what you do and why you do it. But yes, I was also a bit surprised to read such an article on the Debuggable blog ;-)