Great Idea: Property Annotations alternative to getter/setters

Currently, a huge amount of Java objects use property fields with getter/setter accessors:

class MyClass

{

protectedint xyz;

publicint getXyz(){

return xyz;

}

publicint setXyz(int xyz){

this.xyz = xyz;

}

}

.NET uses a slightly simpler syntax which internally generates getter/setter methods:

class MyClass

{

protectedint xyz;

publicint Xyz{

get{

return xyz;

}

set{

xyz = value;

}

}

}

Most of the time (90%+), the getters and setters just set/return. Of course, there are times where it's necessary to implement additional logic without changing the interface presented to other classes. However, there are lots of cases where there is huge amounts of trivial getter/setter code. Also, it takes effort to maintain the getters/setters, when fields are added, deleted, or renamed.

Wouldn't it be much nicer to have trivial getters/setters implied via annotations? Instead of the above examples, do:

class MyClass

{

// defaults to providing both getter and setter.

@PublicProperty

protectedint xyz;

}

You could have variants for protected access, private access, and parameters for getter only or setter only. And, you would continue to use the traditional syntax when you want to do non-trivial getter/setter logic.

The big advantage is that this syntax would be much easier to maintain. Much less code to scroll through. Much easier to rename fields. Easier to delete fields. Easier to add new fields without relying on IDE "generate getter/setter" features.

What does everyone think?

[2747 byte] By [Gamigina] at [2007-10-2 21:05:31]
# 1
Wouldn't this break the following requirement:"Annotations do not directly affect program semantics, but they do affect the way programs are treated by tools and libraries"From: http://java.sun.com/j2se/1.5.0/docs/guide/language/annotations.html
aconst_nulla at 2007-7-13 23:50:50 > top of Java-index,Java Essentials,Java Programming...
# 2

Well, you dont have to put setter and getter in your code if dont want to. Do it if you want them and if you need them. If you think you have fields that dont need setter and getters because they wont have to be used, then just dont write that methods.

setters and getters are a way to implements a small protection for your fields declaring them as privates or something. iif youo dont want the methods then declare the fields as public then yo can access the fields directly from the object.

MelGohana at 2007-7-13 23:50:50 > top of Java-index,Java Essentials,Java Programming...
# 3

It would be great if annotations were capable of doing things like this - I had plans at one point for a powerful @Proxy - but as aconst_null points out, they're not. Or, more precisely, apt isn't, so you'd have to write either your own compiler or a source-to-source translater which inserted the getters and setters.

YAT_Archivista at 2007-7-13 23:50:50 > top of Java-index,Java Essentials,Java Programming...
# 4

MelGohan + dizzy,

Java Beans and every library and framework built on top of Java Beans (such as JSF and EJB 3.0) *require* getters/setters; they aren't an optional design consideration. I could avoid such libraries entirely, but that is extreme.

aconst_null + YAT,

Interesting point about annotation limitations. However, Java Beans based frameworks such as JSF and EJB 3.0 could have support for such annotations. For example, in JSF, when you use {#bean.property}, the framework could check for getProperty()/setProperty() or check for an annotated instance variable named "property".

Or maybe there should be a language level solution to this rather than an annotation-based patch. Any time there is a large volume of rubber stamp code like this, there is probably a better design.

Gamigina at 2007-7-13 23:50:50 > top of Java-index,Java Essentials,Java Programming...