Getter and Setter for Collection...

I think the generation of getters and setters of Collections are still not perfect.

e.g.

private List aList;

--> Generate Getter+Setter
-


public List getGene() {
return gene;
}

public void setGene( List gene ) {
this.gene = gene;
}
-



I would expect something like:
-


public List getGene() {
return Collections.unmodifiableList( gene );
}

public boolean addGene( Object gene ) {
return this.gene.add( gene );
}

public boolean removeGene( Object gene ) {
return this.gene.remove( gene );
}
-


Of course IDEA must ask for the type of the parameter "gene"...




PS: Exists a way to auto-generate "delegate-methods"? Didn?t find it, but can?t believe it is not possible...

8 comments
Comment actions Permalink

PS: Exists a way to auto-generate "delegate-methods"? Didn?t find it, but

can?t believe it is not possible...

Code | Delegate methods.

--
Best regards,
Mike Aizatsky.
-


JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"


0
Comment actions Permalink


I recall this coming up before, and the response was basically "create a live template". That seemed iffy to me, particularly since the built-in getters and setters created are in most cases design flaws (as they cause the contents of an object to become mutable without the object's control or knowlege). Maybe it's time for someone to create a plugin...

0
Comment actions Permalink

Yeah, you´r right. It´s not some kind of cosmetic feature. Giving away control over your internal Collections has a very bad smell ;).

0
Comment actions Permalink


Strongly agreed. I've added inspections to my upcoming InspectionGadgets plugin that warn if you return a Collection or array field, or if you assign one from a method parameter. Things have to be extremely performance-sensitive for these constructs to make sense.

0
Comment actions Permalink

"performance-sensitive" (?)

How much faster is

foo.addBar(bar)

than

foo.getBars().add(bar)

0
Comment actions Permalink

"Performance sensitive" code would actually sharing the collections, with all the headache and danger that entails, rather than copying them. In that case, the comparison is between

foo.setBars(myBigCollection); //internally this just do an assignment to an instance variable

and

foo.addBars(myBigCollection); //internally this calls .addAll()

which could actually be quite a big speed/footprint difference, if it occurs deep in inner loops.

It's rare that this sort of cowboy nonsense is worthwhile, but it happens. IDEA's bean automation should be targetted to the common (and safe) case.

0
Comment actions Permalink

Hm, I often hold an unmodifiable wrapper for my collections and pass that out:

This prevents callers from changing A's state and avoids having to copy the list before passing it out.

0
Comment actions Permalink

Yes, that may be more performant...

But the point is: We should write code for humans not for computers. I think it is much more important to program in an understandable way than to improve performance by some miliseconds (especially if that code isn´t used very often).

Performance-Improvement is important. But please use a profiler before! Don´t optimize with a blind eye...

0

Please sign in to leave a comment.