The Collections Framework API is much smaller than it would have been had it exported forty-five separate public classes, one for each convenience implementation. It is not just the bulk of the API that is reduced but the conceptual weight: the number and difficulty of the concepts that programmers must master in order to use the API. The programmer knows that the returned object has precisely the API specified by its interface, so there is no need to read additional class documentation for the implementation class.
>The programmer knows that the returned object has precisely the API specified by its interface
This isn't completely true / let's not completely overlook the drawbacks.
For example, the List returned by Collections.unmodifiableList does have a "reduced weight" — e.g., there's isn't a different UnmodifiableList class or interface — but that means there's also no static indication that the returned list is unmodifiable. The consumer(s) who it's given to (and it could be passed from one consumer to another) just has to know its unmodifiable (did JavaDoc along each step of the way convey this information?), lest he only find out at runtime that trying to modify it results in an UnsupportedOperationException.
