Excerpts from Ketan Padegaonkar's blob
"Why do we need getters and setters anyway ? Do they not break encapsulation ? There’s two schools of opinions I’ve come across here. One that likes to follow the javabeans specfications. The other that says hates getters and setters for the reason that objects then tell you who their friends are (Disclosure: I belong to such a group). Objects should expose behavior and not their friends that may help you out."
Interesting!!! Now lets analyse a few points on getters and setters.
Objects like value objects and model elements which are used to store only data will require getters and setters to access the stored data. What about the rest of objects which we see in our daily developer life. Can we live without getters and setters in those objects?
For eg: (In Java)
Parser parser = new Parser("c:\temp\FileToParse.xml");
parser.parse();
parser.getFile();
The 'parser. parse()' method makes sense. What about the 'parser.getFile()' method?
The parser will return the current file which it has parsed. Can we live without this getter? This is an extra information. Do we need to expose this extra information to the user of this parser?
Extra info is always useful. But isn't too much info cumbersome?
Are these extra getters adding oil to the current fire of 'lots of dependencies between packages' which is the case of many huge applications we see today? One day these haphazard dependencies will kill these applications one after the other.
If the getFile() method is exposed by the parser, it will be used by some of the client programs. But if the getFile() method is not exposed by the parser, then the client will depend on the parser to only invoke the 'parse()' method.
The above example is too simple. But hope you got my message.
Subscribe to:
Post Comments (Atom)
I feel that at the end of the day, it is upto the client to decide which methods to use for its own purpose. If, for eg, the client does not use the getFile method initially as it is not supported, but then due to customer demand, it needs such functionality, the client now will have to find another parser that provides this info.
ReplyDeleteIf you want a maintainable and extensible application, the mantra is 'reduce dependencies between modules'.
ReplyDeleteIf the client program has passed a file name to the parser, its the responsibility of the client program to maintain the filename.
May be we can attribute this to the 'Single Responsibility Design Principle'. A class should do what its supposed to do. And nothing else.
Again I am not 100% sure about the practicality of this approach. I need to try out this in a live module.
Madhu Said:
ReplyDeleteObjects like value objects and model elements which are used to store only data will require getters and setters to access the stored data. What about the rest of objects which we see in our daily developer life. Can we live without getters and setters in those objects?
My Comment:
This may not *always* be the case. If a client objects need the private members for some reasons, it's probably because it wants to do something with it.
For e.g. You may need the 'value' in a value object purely for comparison, in which case you could do implement a #compareTo(anotherValue) or addTo(anotherValue) and something similar.
I agree with Madhu's comment here, about being careful of what you expose, exposing getFile() just because someone 'may' need it, will mean that someone 'will' use.
Needless to say that the parser is also now tied down to a File implementation, and there's no way to use the parser to parse say from an inputstream or a reader, because the parser exposes #getFile().