Although I am inclined to agree with some of the points made I would not make a blanket generalization about accessor methods like that. They can be detrimental to your design.
This article at the javaworld website enumerates the argument against get/set methods. It goes even further than I would in arguing against accessor methods but I feel that it brings up some important points.
Here is a quote from the article that gives you an idea of the angle it takes:
"Getter and setter methods (also known as accessors) are dangerous for the same reason that public fields are dangerous: they provide external access to implementation details. What if you need to change the type of the accessed field? You also have to change the accessor's return type. This return value is used in numerous places, so you must also change all of that code. I want to limit the effects of a change to a single class definition. I don't want them to ripple out into the entire program.
Since accessors violate the principle of encapsulation, you can reasonably argue that a system that heavily or inappropriately uses accessors simply isn't object oriented."
The simplest example of this is changing an internal data structure from an array to a hash. If you have get and set methods for it you have to go out to every place in your code where you pulled the array out with a get() method (and put it back with a set() call) and fix the code to handle a hash. This violates the data encapsulation principle of OO.
In reply to Re: Re: Make your classes use their own methods
by synistar
in thread Make your classes use their own methods
by petdance
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |