Allen Holub wrote the following,
You can’t have a program without some coupling. Nonetheless, you can minimize coupling considerably by slavishly following OO (object-oriented) precepts (the most important is that the implementation of an object should be completely hidden from the objects that use it). For example, an object’s instance variables (member fields that aren’t constants), should always be private. Period. No exceptions. Ever. I mean it. (You can occasionally use protected methods effectively, but protected instance variables are an abomination.)
Which sounds reasonable, but he then goes on to say,
You should never use get/set functions for the same reason—they’re just overly complicated ways to make a field public (though access functions that return full-blown objects rather than a basic-type value are reasonable in situations where the returned object’s class is a key abstraction in the design).
Which, frankly, just sounds insane to me.
I understand the principle of information hiding, but without accessors and mutators you couldn’t use Java beans at all. I don’t know how you would follow a MVC design without accessors in the model, since the model can not be responsible for rendering the view.
However, I am a younger programmer and I learn more about Object Oriented Design everyday. Perhaps someone with more experience can weigh in on this issue.
I don’t have a problem with Holub telling you that you should generally avoid altering the state of an object but instead resort to integrated methods (execution of behaviors) to achieve this end. As Corletk points out, there is wisdom in thinking long and hard about the highest level of abstraction and not just programming thoughtlessly with getters/setters that just let you do an end-run around encapsulation.
However, I have a great deal of trouble with anyone who tells you that you should “never” use setters or should “never” access primitive types. Indeed, the effort required to maintain this level of purity in all cases can and will end up causing more complexity in your code than using appropriately implemented properties. You just have to have enough sense to know when you are skirting the rules for short-term gain at the expense of long-term pain.
Holub doesn’t trust you to know the difference. I think that knowing the difference is what makes you a professional.