Question

I’m writing a small API to deal with objects that have specific ‘traits’ In this case, they all have an interval of time and a couple of other bits of data, So I write an interface TimeInterval with some getters and setters.

Now most of these API methods deal with a Set or List of Objects. Internally these methods use the Java Colletions Framework (HashMap/TreeMap in particular). So these API methods are like:

getSomeDataAboutIntervals(List<TimeInterval> intervalObjects);

Couple of Questions:

a) Should this be List<? extends TimeInterval> intervalObjects instead?

Is it mostly a matter of style? The one disadvantage of taking strictly an interface that I can see is, you need to create your list as a List<TimeInterval> rather than List<ObjectThatImplementsTimeInterval>.
This means potentially having to copy a List<Object..> to List<TimeInterval> to pass it to the API.

Are there other pros & cons to either approach?

b) And, one dumb question 🙂 The collections framework guarantees I always get out the same instance I put in, the collections are really a collection of references, correct?

Answer 1

1) Yes.

Method parameters should be as general as possible. List<? extends A> is more general than List<A>, and can be used when you don’t need to add things to the list.
If you were only adding to the list (and not reading from it), the most general signature would probably be List<? super A>

Conversely, method return types should be as specific as possible. You rarely to never want to return a wildcard generic from a method.

Sometimes this can lead to generic signatures:

<T extends MyObject> List<T> filterMyObjects(List<T>)

This signature is both as specific and as general as possible

2) Yes, except possibly in some rare very specific cases (I’m thinking of BitSet, although that isn’t technically a Collection).