My two cents:
There are two meanings of subtyping Collection (or any other interface, for that matter) -
additional logic and specific implementation.
I think wherever possible, we should use the interface that infers as much logic as
possible (e.g., java.util.List for ordering, java.util.Set for uniquness,
java.util.SortedSet for natural ordering, etc.), without inferring any specific
implementation (e.g., ArrayList, HashSet, etc.).
The flipside of this notion is that it's a mistake to use an overly specific
class/interface - when your parameter type is ArrayList, you implicitly tell the user the
*order* of his objects matter, and that it matters to your internal algorithm to be able
to do get(i) as an O(1) operation.
Bottom line, now that I'm done with CS 101:
+1, but be careful not use interfaces that are too low.
Most methods that now receive an ArrayList will still compile if you change the parameter
type to Collection, but make sure that you don't implicitly assume some ordering,
e.g.
-Allon
----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
To: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Thursday, March 1, 2012 5:18:03 PM
Subject: [Engine-devel] Use java.util.Collection where possible?
Hi,
I see that in some places in engine-core we use Java.Util.List, or
even
Java.Util.ArrayList as types of method arguments, while in the method
code we do nothing besides iterating over the collection.
I then found all kinds of usages like this:
x.foo(new ArrayList<MyType>(myMap.values()));
As you can see need to instantiate a new ArrayList in order to use
the
values of the map in method foo.
Do you see any reason why not change the argument type (at method
signature) to Collection in such places, where possible?
Yair
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel