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...
请先登录再写评论。
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!"
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...
Yeah, you´r right. It´s not some kind of cosmetic feature. Giving away control over your internal Collections has a very bad smell ;).
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.
"performance-sensitive" (?)
How much faster is
foo.addBar(bar)
than
foo.getBars().add(bar)
"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.
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.
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...