Skip to main content

Automatically create getters and setters

9 replies [Last post]
whitfordny
Offline
Joined: 2006-09-24

When writing classes, I generally start with defining the private fields, then will use Eclipse to generate the public getters and setters. I like to Javadoc each field, but that Javadoc then needs to be repeated two more times (get and set), so I end up with needing to maintain 3 copies of the documentation.

Generally, how important is it that we declare getters and setters? Why couldn't we simply declare fields as Read-Only or Read/Write and have the getters and setters generated automatically by Java?

For example:

<br />
public class Foo<br />
{<br />
    /** Attribute that is not able to be changed, only defined by constructor, hence read-only. */<br />
    @Get<br />
    private String someReadOnlyAttribute;</p>
<p>    /** An attribute that is read/write. */<br />
    @Get @Set<br />
    private String attributeOne;</p>
<p>    /** Another read/write attribute. */<br />
    @Get @Set<br />
    private String attributeTwo;</p>
<p>    public Foo (final String someReadOnlyAttribute)<br />
    {<br />
        this.someReadOnlyAttribute = someReadOnlyAttribute;<br />
    }<br />
}<br />

I do agree that sometimes there is value to defining an explicit getter or setter, so that ability needs to be preserved (also for backwards compatibility), but 90% of the time a standard shell is sufficient.

Could something like this be considered for JDK 7?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jwenting
Offline
Joined: 2003-12-02

quote often you don't want "standard" getters and/or setters.
And I've a deeply rooted distrust of code generators of any kind anyway, especially those that generate code I can't alter after it's been generated because it's either generated at a stage I've no control over or my changes are either ignored or cancelled out by the system after I make them (Netbeans and IBM take notice!).

kcpeppe
Offline
Joined: 2003-06-15

these do seem like useful annotations.. Quite frankly writting get/set code is boring. I'd extend the annotation to include visibility hints. I don't always want get/set to be public.

leouser
Offline
Joined: 2005-12-12

if this code-generating annotation was created, would it make sense to have some options as what is generated. Probably common code patterns. Instead of just

@Set
Object thing

produces:
public void setThing(Object thing){
this.thing = thing;
}

Allow for event generation as well:
@Set(PropertChangeEvent=true)

produces:
public void setThing(Object thing){
Object oldThing = this.thing;
this.thing = thing;
firePropertyChangeEvent("thing", oldThing, thing);
}
-----------
this might be a stretch... :(

leouser

mthornton
Offline
Joined: 2003-06-10

How about just change JavaDoc so that getters and setters could inherit documentation from a field. This eliminates the duplication of documentation.

soupdragon
Offline
Joined: 2006-01-07

> How about just change JavaDoc so that getters and
> setters could inherit documentation from a field.
> This eliminates the duplication of documentation.

In fact you could add a generalised "{@include}" type tag in javadoc that would copy blocks of documentation from other objects. That way the refactoring process could just place a reference to the field documentation when creating getters and setters which wouldn't have to be changed when the field documentation was.

whitfordny
Offline
Joined: 2006-09-24

I like the JavaDoc ideas!

I'm trying to make a concerted effort to improve the level of documentation, and apply the DRY principle.

kennardconsulting
Offline
Joined: 2005-10-25

I think ideally the situation would be:

Given a statement 'foo.x', the VM...

1. First tries to find a 'getX()' method
2. Next tries to find a public 'x' member
3. Errors

...that way, we could all start off building our classes as mostly public members and there would be no penalty if we later wanted to swap one for a getter/setter instead.

Of course, this requires the JavaBean convention actually be baked-in to the JVM, and would probably be a breaking change :(

jwenting
Offline
Joined: 2003-12-02

it would also require a core language change, redefining members to be equivalent to their getters and setters.

Very, very, bad. Would be even worse than the fundamentally broken garbage that's the featureset of Mustang.

soupdragon
Offline
Joined: 2006-01-07

It's an interesting idea - though I don't think it really fits in as a suitable use for annotations (which are more at the "hint" level as far as the compiler is concerned.

However I think it's going to be a bit disruptive of debugging - the creation of methods without source code.

I know what you mean about commenting, though, it's irritating to have to maintain Javadocs on the field, the getter and the setter. Mind you refactoring tools could be a bit more helpful there.