tags:

views:

250

answers:

6

I actually happily design and develop JEE Applications for quite 9 years, but I realized recently that as time goes by, I feel more and more fed up of dragging all these ugly bean classes with their bunch of getters and setters.

Considering a basic bean like this :

public class MyBean {

    // needs getter AND setter
    private int myField1;

    // needs only a getter, no setter
    private int myField2;

    // needs only a setter, no getter
    private int myField3;

    /**
     * Get the field1
     * @return the field1
     */
    public int getField1() {
            return myField1;
    }

    /**
     * Set the field1
     * @param value the value
     */
    public void setField1(int value) {
            myField1 = value;
    }

    /**
     * Get the field2
     * @return the field2
     */
    public int getField2() {
            return myField2;
    }

    /**
     * Set the field3
     * @param value the value
     */
    public void setField3(int value) {
            myField3 = value;
    }

}

I'm dreaming of something like this :

public class MyBean {

    @inout(public,public)
    private int myField1;

    @out(public)
    private int myField2;

    @in(public)
    private int myField3;
}

No more stupid javadoc, just tell the important thing...

It would still be possible to mix annotation and written down getters or setters, to cover cases when it should do non-trivial sets and gets. In other words, annotation would auto-generate the getter / setter code piece except when a literate one is provided.

Moreover, I'm also dreaming of replacing things like that :

MyBean b = new MyBean();
int v = b.getField1();
b.setField3(v+1);

by such :

MyBean b = new MyBean();
int v = b.field1;
b.field3 = v+1;

In fact, writing "b.field1" on the right side of an expression would be semantically identical to write "b.getField1()", I mean as if it has been replaced by some kind of a preprocessor.

It's just an idea but I'm wondering if I'm alone on that topic, and also if it has major flaws.

I'm aware that this question doesn't exactly meet the SO credo (we prefer questions that can be answered, not just discussed) so I flag it community wiki...

+10  A: 

You might be dreaming of Project Lombok

sfussenegger
Neat. I'd not seen that before
Brian Agnew
Woaw ! Indeed, at least for the bean side, it makes my dream come true. I'm gonna test it right now !
zim2001
Just found this and WOW. Also check out @SneakyThrows.
Mark Renouf
The only major issue I have with Project Lombok is that it doesn't play nice with AspectJ/AJDT.
Anonymouse
+3  A: 

There has been alot of discussion about this topic already because people wanted it included in Java 7. A good summary of links can be found on http://tech.puredanger.com/java7#property

Project Lombok partially fills this hole: it handles the generation of getters and setters (and other stuff). But using the field-access syntax to access getters and setters isn't possible this way.

Wouter Coekaerts
A: 

You could write your beans in Groovy. Groovy classes work seamlessly with Java classes and you can compile Groovy and Java code in a single step using Groovy's cross-compiler. The Groovy equivalent of the bean you've shown above is

public class MyBean {

    // read-write Groovy property
    int myField1    

    // read-only Groovy property
    final int myField2 

    // write-only Groovy property
    private int myField3
    public setMyField3(int value) {
        this.myField2 = value
    }
}

As you can see the syntax for read-write or read-only properties is very succinct, though no such syntactic sugar exists for write-only properties (though these are relatively rare in my experience).

Not only is the Groovy syntax for declaring properties very succinct, so is the syntax for accessing them (in Groovy code):

MyBean myBean = newBean(myField1: 6, myfield2: 6, myfield3: 6)

// Setter access
myBean.myField1 = 5

// Getter access 
println "myField1 value: " + myBean.myField1

If you want to access the properties from Java code, you use the usual getXXX and setXXX methods that are generated "behind the scenes".

This more succinct syntax for defining beans is just one of many examples of how using Groovy can really reduce the need for boilerplate code.

Don
A: 

Scala also provides annotations for creating classes that behave just like beans. Consider the following example

class ScalaBean(@BeanProperty var propOne : String){
  @BeanProperty var propTwo : Float = 2;
}

This annotation creates the get and set Java methods using JavaBeans convention. Here I've shown one property declared in what you could consider a constructor and another in the class body. The nice thing about this is that the class retains the static typing you get in Java.

Bear in mind that these methods will only be seen from Java and not the Scala world. In Scala you see the them as properties which you can set using the equals operator.

Randaltor
A: 

psst, you could come over to the world of POJOs. where you can do things like

public class MyBean {
    public int myField1;  // in and out.

    public final int myField2; // out only.

    public MyBean(int myField2) {
        this.myField2 = myField2;
    }
}

;)

Peter Lawrey
POJO means "Plain Old Java Object", it doesn't imply anything about having or not having accessors. What you've shown is going to be painful to refactor when you find that you actually need to use a long, or BigDecimal or something else internally. All code that touches that class needs to be modified.
Mark Renouf
Also: that class won't compile as you've not initialized myField2 in the constructor.
Mark Renouf
@Mark a common argument but one which almost never happens and isn't much cost as some claim. More often its the case that YAGNI holds and you have added code which will have to be maintained but will never be needed.
Peter Lawrey
This is a problem if you are writing a public library where you have no control over how it is used. However, if you have a code base which is controlled locally (i.e. you can checkout and change the code all at once) the cost is minimal.
Peter Lawrey
An example I give is pet-store sample application written more than 7 years ago. There is only three getter/setters in the data model that actually do anything and these can all be eliminated very easily.
Peter Lawrey
Thank you for pointing out it need a constructor. ;)
Peter Lawrey
A: 

Do you use and IDE that has features like this built in. For example Eclipse will allow you to generate the getter/setter methods of your choice for your class. A question I have is how are you going to deal with taking the object that has a "default" setter, and change that to a custom setter?

Milhous
zim2001