Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Doing away with getters and setters
URL: Say No to Properties Boilerplate!
At 3:50 PM on Jun 14, 2006, Michael Urban wrote:
Fresh Jobs for Developers Post a job opportunity
In Cay Horstmann's blog, he talks about a system one of his master's degree students came up with for using annotations to generate this boiler plate code (the current system uses ant tasks and extensions to javac.) Instead of having getters and setters, you can just do something like this:
Furthermore, you can access the property by doing something like the following:
instead of calling an accessor method.
However the problem with the current system is that according to the specification for ejb3 annotations, annotations cannot cause code to be generated. So there are some other ideas about how this could actually be implemented. For example, int @id;
Definitely some interesting ideas, although I don't know how found I am of going down the "Perl road of magic prepend symbols" for variables.
What's your opinion? Should a system like this be adopted in Dolphin to do away with accessor methods?
The original article is here
56 replies so far (
Post your own)
Re: Doing away with getters and setters
The entire point of getters/setters is that you get to control what goes inside them. If you autogenerate them to some default you might as well access the fields directly.In my view, this is something that is best handled at the IDE level (autogenerate these methods) instead of at the annotation level (can't insert code into the getter/setter method).
Re: Doing away with getters and setters
> The entire point of getters/setters is that you get> to control what goes inside them. If you autogenerate
> them to some default you might as well access the
> fields directly.
True, but the problem still remains. 99% of these getters/setters are just boiler plate passthroughs to the property. People still create them because there might be an off chance that in the future you will need to add some behavior and it would be much harder to refactor a field into getter/setter combo. So it makes sense to autogenerate them from the start, but that leaves you with with heaps of code that doesnt need to be there.
This really does need to be a language feature with a syntax that is very short for default behavior but easily expendable for when you want to introduce something more complex.
Re: Doing away with getters and setters
Looks a lot like old groovy code to me. It used the @property mechanism to define properties, though now they have gotten rid of that and just made the getters and setters transparent.Re: Doing away with getters and setters
How about using the BeanShell scripting language. It's Java compatible, and handles it automatically.Rhino Javascript does it as well.
They introspect the class and uses the accessor method if it can, otherwise it accesses the field directly.
item.id = 123;
Another reason for scripting is the ability to adjust the code without having to recompile. Only watch JBoss start up once or twice a day instead of again and again and again.
Unfortunately, the BeanShell guy didn't quite do it right. It's not as "live" as it should have been.
Re: Doing away with getters and setters
Why this '@' in int id=item.@id, it would be a nice shorthand for item.getId() to simply write item.id and accordingly item.id=4 for item.setId(4) (to make this consistent setX must be defined as T setX(T value) )As long as one can 'override' these synthetic accessor I don't see a problem with that, besides that it isn't transparent anymore how an assignment behaves. Even that I don't find disturbing as the worst thing with accessors I can imagine is that they don't behave as such:
void String getA() { return _a=_a+"!"; }
as it fails to meet nearly any expection one has when he encounters a getter.
What is the purpose of getters and setters, why do we need them?
The first question that should be asked is: what is the purpose of setters and getters and why do we need them?One of the main reasons for using setters and getters is called encapsulation: hide the implementation of the class for the outside world. Getters and setters are used to provide access to the payload of the class in a controlled way: the logic in the getters and setters determine what is allowed and which rules apply. Also you should always try to minimize the public interface of the class to the absolute minimum. And yes, I know in the case of data objects almost always the complete payload is exposed using setters and getters but then there's a good reason for it.
Are there any other reasons for using setters and getters?
This means there's at least one reason for the existence of setters and getters. Right?
Now, in most cases the setters and getters only contain very basic straightforward typical setter and getter code. I prefer to generate as much as possible of this because I want to spend as less time as possible to produce trivial code. Since they are so trivial you could argue to drop them. However, if we do this then how are we going to protect and control access to the payload of the class? So maybe that's not such a good idea?
You have my vote for other (better?) ways of controlling access to the class payload and generating all needed boiler plate code or other mechanism for controlling access.
Martin Fowler also has something interesting point about this topic in his article "GetterEradicator" (http://martinfowler.com/bliki/GetterEradicator.html). Go check it out!
Re: What is the purpose of getters and setters, why do we need them?
Believe it or not, many people work with stupid data that gets passed from A to B and back to A.You can imagine some fancy stuff to avoid having such accessors, but it will mostly an overkill.
The 'getters considered harmful' aims at this pseudo OO design that manipulate 'structs' and merely hide all attributes behind accessors. Note the difference between attributes and properties.
The get/set convention comes from JavaBeans, and some people truely believe that a class full of accessors is a JavaBean (this is so striking that they become system-architect).
Re: Doing away with getters and setters
If you don't want getters and setters don't make any. If you use any modern IDE some wizard will create them for you. I bet the C# guys complain about how properties are handled in C#.To answer your question: No, the java language does need properties to be implemented this way.
Getters and setters are evil
Allen Holub pointed out back in 2003 that setters and getters are evil. He makes a good point!http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
Re: Doing away with getters and setters
You mean like what C# does?Steve
Re: Doing away with getters and setters
> You mean like what C# does?>
> Steve
Not really, the syntax in c# is awkward imho. What I want is a quick way to tell the compiler to generate the getters/setters for me if I didnt do it myself.
What I would like is something like this:
class Foo() {
@Property(Modifier.PUBLIC&Modifier.FINAL)
private String name;
public String setName(String name) {
this.name=name;
}
}
Here the annotation(or however it is implemented) tells the compiler that getters/setters should be generated. My setter overrides the default (the default is not generated).
Now in my code I can do new Foo().getName() which will use the default setter and new Foo().setName(name) which will use the one I declared
I really havent given it much thought, but I think something like this would be nice. Any time I create a bean for a form or what not I always generate the setters/getters and thats ok, but a class that could've been 10 lines of code is now 50 which is a waste I think.
At the end this is syntactic sugar, but I think a case can be made that it is needed.
Re: Getters and setters are evil
He didn't win too many friends with that article, that's for sure.He advocated putting ALL logic in the object which from the the 10,000 foot view made some sense. But in practice, it just doesn't make sense.
Re: Doing away with getters and setters
This is pretty much what I've been wanting as well! The one final potential twist would be to export/expose the private variable name with a "public" field name.Definitely boilerplate to the average getter/setter is pointless. Imagine how much useless code would be dropped instantly...
Re: Doing away with getters and setters
Automatic transparency is a possibility worth exploring...