Trends: Getters and Setters, going the way of the dinosaur?
Like all developers I was always taught to use getter and setters to access the internal members of an external class, and up until recently I accepted this idiom blindly. Not too long ago I was on a discussion board when a young developer asked what the getters and setters were doing in a snippet of code. I proceeded to explain what each method did, I then was about to explain why getters and setters are used, but I couldn't. I know the old adages, hiding a class' implementation, data hiding, etc. But none of the explanations really “stuck” when I thought about them. After all I am de facto exposing a class' member to the entire world by creating a public getter method. I did a bit of researching and there is quite a bit of discussion on this subject, found these articles to very informative and do a good job of framing the subject:
http://www.javaworld.com/javaworld/jw-01-2004/jw-0102-toolbox.html
http://www.darronschall.com/weblog/2005/03/no-brain-getter-and-setters.cfm
No related posts.
Categories
Tag Cloud
Archives
- November 2009 (3)
- October 2009 (18)
- September 2009 (15)
September 23rd, 2009 - 01:14
In my opinion, C# is one of the best here. You can create properties like this:
class A {
public int X {get; private set;}
}
This gives you a value that can be set within the class and got from outside the class. Later, if you need to, you can supply a body for one of these; so the code becomes:
class A {
int x;
public int X {get {return x;} private set {x=value;/* do something*/}}
}
C# is not my favorite language, but I do like this feature.
September 23rd, 2009 - 02:34
In .NET, you can’t use some stuff like data binding or XML serialization without properties. It’s stupid, but that’s the world I live in.
September 23rd, 2009 - 08:03
Schall’s article is talking about Flash. If only Java had the same feature (of allowing you to change from public variables to getters without changing clients). It would be a whole different story.
September 23rd, 2009 - 09:43
Let’s not forget about Obj-C’s wonderful @property (with various attributes) and @synthesize to expose object members get/set methods.
September 23rd, 2009 - 10:04
Java, unlike for example C# and Scala, does not support the uniform access principle: http://en.wikipedia.org/wiki/Uniform_access_principle
And therefore we have ugly and verbose getter and setter methods.
I think it’s unlikely that Java is going to support the uniform access principle any time soon.
September 23rd, 2009 - 17:23
In VB you dont even need to change your client code, you just have to recompile. But even that isnt good enough because if you dont recompile you break backwards compatibility.
October 9th, 2009 - 02:20
I was NEVER taught to use getter and setters to access the internal members of an external class. I think you pretty much misunderstand the issues of encapsulation and information hiding. How does having a setter/getter pair “hides class’ implementation”? Also, what kind of classes are you talking about, what kind of problem are you solving?
October 9th, 2009 - 08:53
Trust me, you will appreciate them the moment you have to change the implementation of a property on a commonly used class. That happened to me, but since the variables were protected instead of private I basically had to refactor 1200 class files to get them to use the getter.
October 22nd, 2009 - 11:16
For simple immutable value objects (in Java) that are nothing but containers for the attributes, then I have recently begun exposing the property directly by making it public. But that requires the values be passed in via the constructor or retrieved there, or made with a helper (which seems like a lot of trouble and adds extra maintenance and logic that can have bugs in it). So when there are more than a few properties that kind of falls flat on its face – who wants a constructor with 20 arguments? I use these ‘public’ immutables for simple tuples of arguments that need to be grouped together when there are less than say 5 or so properties.
But what do getters/setters hide? Sometimes they hide validation. Sometimes they hide construction or retrieval of the property from somewhere else. Sometimes they hide a calculation. Sometimes they throw an exception if the argument isn’t valid. Right now they might just be doing a “return myInt;”, but tomorrow I may change that method to do something more complicated and then I don’t have to go out and change the 50 different other classes that call the setter/getter.
Then there is the cases where:
a) You are using IOC/DI to set the properties in something like a Spring bean.
b) You are using something like iBatis where setters/getters are the convention for creating some bean from some mapped SQL.
c) You are implementing an interface where maybe someone else wants to add a proxy via AOP to wrap the getter/setter with additional code (validation, etc.)
October 22nd, 2009 - 11:48
Still, it will be nice when Java supports UAP – there was some talk of supporting ‘properties’ (like C# does) in JDK 7, but I don’t think that will happen this time around. Of all of the changes in JDK 7, I would have preferred ‘properties’ support and improved null syntax/handling to be towards the top of the list.
Many IDEs will generate your getters/setters for you.
November 12th, 2009 - 09:46
Surely they are useful in case you ever need to change the simple member access to something more complex. As others have already said exposing the member variables directly is dangerous. What if you ever needed to do validation before storing the value?
November 12th, 2009 - 10:21
I was taught to do getters and setters in Java for one reason:
Implementation hiding
It might look like a field of a class is only there to hold a value, but down the road, you might want to add validation to the setter or a different type of getter (calculated from another value or retrieved from a database).
November 12th, 2009 - 10:21
building object-oriented software without the use of getters (and setters) was one of the drivers behind what we now know as Mock Objects. See http://peripateticaxiom.blogspot.com/2008/06/tdd-mocks-and-design.html for a discussion.
The more general case is to “tell, don’t ask” and not enquire about the properties of objects at all.
November 12th, 2009 - 13:56
I think there’s a danger here of folk blindly applying a design rule (”don’t use getters and setters”) without applying any thought as to the reasons why.
The less objects know about each other, and the more data and associated behaviour can be internalised within objects, the less coupling there’ll be between objects and therefore the easier it will be to make a change to one class without impacting on other classes.
“Don’t use getters and setters” is no more a design insight than “singletons are bad” or “use dependency injection”.
Objects have to share data. Otherwise you would have to put everything in one class. The goal is to minimise the amount of sharing and maximise the internal cohesion of classes. Not to do away with accessor methods.