|P is for Practical|
Why get() and set() accessor methods are evilby synistar (Pilgrim)
|on Nov 25, 2003 at 16:46 UTC||Need Help??|
Here on PM get() and set() methods seem to be pretty commonly advocated for. I think there are some pretty good reasons why their overuse should be avoided in object oriented designs. The primary problem with them is that they can defeat the data encapsulation principle of OO design.
Here is a simple example:
Later on we use the accessor:
If we later decide to change the implementation of our list to a hash our loop will also process the hash keys (this would most likely not be what we want). We have to change code outside our object to conform with the new internal data structure of the object. The accessor method is breaking our data encapsulation. set() methods are especially vulnerable to this.
Accessor methods should be used cautiously
UPDATE: I agree this example is pretty flimsy. But I wanted an example that didn't require to much explanation. A better example might be an accessor that returns a hash generated by an internal sub. Bugs or changes in the hash generating sub could affect code outside of the object. The point I was trying to emphasize is the fact that a connection exists between code outside of your object and the internal data representation. The accessor methods are what create this undesirable dependancy.
UPDATE: After looking at this meditation again and thinking about some of the great comments, I agree with some of the other monks that the tone this node takes is a little too harsh. I primarily wanted to give a warning for people new to OO. The "make an object by just giving it a bunch of public accessors" approach seems to be a common mistake. However, there are good reasons for using them sometimes. And when you do use them realize that they are a major portion of your object's interface.
A lot more has been written about this elsewhere:
Another way out of this hole is to return whole objects:
Both links are Java articles but the design issues are universal.