Is there a good reason to use Java's Collection interface?

Question

I've heard the argument that you should use the most generic interface available so that you're not tied to a particular implementation of that interface. Does this logic apply to interfaces like java.util.Collection?

I would much rather see something like the following:

List<Foo> getFoos()

or

Set<Foo> getFoos()

instead of

Collection<Foo> getFoos()

In the last case, I don't know what kind of data set I'm dealing with, whereas in the first two instances I can make some assumptions about ordering and uniqueness. Does java.util.Collection have a usefulness outside of being a logical parent for both sets and lists?

If you came across code that employed Collection when doing a code review, how would you determine whether its usage is justified, and what suggestions would you make for its replacement with a more specific interface?

Answer 1

Abstractions live longer than implementations

In general the more abstract your design the longer it is likely to remain useful. So, since Collection is more abstract that it's sub-interfaces then an API design based on Collection is more likely to remain useful than one based on List.

However, the overarching principle is to use the most appropriate abstraction. So if your collection must support ordered elements then mandate a List, if there are to be no duplicates then mandate a Set, and so on.

A note on generic interface design

Since you're interested in using the Collection interface with generics you may the following helpful. Effective Java by Joshua Bloch recommends the following approach when designing an interface that will rely on generics: Producers Extend, Consumers Super

This is also known as the PECS rule. Essentially, if generic collections that produce data are passed to your class the signature should look like this:

public void pushAll(Collection<? extends E> producerCollection) {}

Thus the input type can be E or any subclass of E (E is defined as both a super- and sub-class of itself in the Java language).

Conversely, a generic collection that is passed in to consume data should have a signature like this:

public void popAll(Collection<? super E> consumerCollection) {}

The method will correctly deal with any superclass of E. Overall, using this approach will make your interface less surprising to your users because you'll be able to pass in Collection<Number> and Collection<Integer> and have them treated correctly.

Answer 2

The Collection interface, and the most permissive form Collection<?>, is great for parameters that you accept. Based on use in the Java library itself it's more common as a parameter type than a return type.

For return types, I think your point is valid: If people are expected to access it, they should know the order (in the Big-O sense) of the operation being performed. I would iterate over a Collection returned and add it to another Collection, but it would seem a bit crazy to call contains on it, not knowing if it's a O(1), O(log n), or O(n) operation. Of course, just because you have a Set doesn't mean it's a hashset or a sorted set, but at some point you will make assumptions that the interface has been reasonably implemented (and then you'll need to go to plan B if your assumption is shown to be incorrect).

As Tom mentions, sometimes you need to return a Collection in order to maintain encapsulation: You don't want implementation details leaking out, even if you could return something more specific. Or, in the case Tom mentioned, you could return the more specific container, but then you'd have to construct it.

Answer 3

I'd look at it from the complete opposite point of view, and ask:

If you came across code that employed List<> when doing a code review, how would you determine whether its usage is justified?

It's quite easy to justify this. You use the List when you need some functionality that is not offered by a Collection. If you don't need that extra functionality - what justification do you have? (And I won't buy, "I'd prefer to see it")

There are plenty of cases where you will be using a collection for read-only purposes, populating it all at once, iterating through it entirely - do you ever need to index the thing manually?

To give a real example. Say I perform a simple query on a database. (SELECT id,name,rep FROM people WHERE name LIKE '%squared') I grab back the relevant data, populate Person objects and put em into a PersonList)

• Do I need to access by index? - Would be meaningless. There's no mapping between index and ID.
• Do I need to insert at an index? - No, the DBMS will decide where to put it, if I'm adding at all.

So what justification would I have for those extra methods? (which would be left unimplemented in my PersonList anyway)