Re: Arrays of types...

From: justaguy (justaguy_at_nospam.net)
Date: 10/16/04


Date: Sat, 16 Oct 2004 15:14:26 -0400


> Tony Morris coughed up:
>>A List implementation should never ever ever be subclassed - it's
>>just plain fugly.

I firmly beg to differ. If that were so, we'd never see classes like
javax.management.AttributeList, java.util.Stack or java.util.Properties.

The ability to subclass is, in fact, one of the raisons d'^etre for
having collection classes in the first place. Quite aside from the
ontological certainty that all statements of the form, "We should never,
ever, ever do X!" are false, not to say destructively limiting, think
about why one might wish to subclass a List implementation, or any other
Collection class for that matter.

Subclassing is creation of "Is-A" relations. There are many things in
the world that one might wish to model as a collection with additional
properties. Examples abound on Sun's site, in various tutorials and
white papers. For example, consider a "Bag" class, containing labeled
items (label is key, item is value), with additional semantics on the
item values. Collection classes HashMap, TreeMap, etc., have already
solved the parts of the problem relating to finding items with the same
label, preventing collisions, inserting many items from other
collections, and so on. All Bag has to do is extend one of those and
add the behaviors unique to its needs. Furthermore, you get things like
the Collections static methods for free this way.

This is a common pattern, and the ability to extend a Collection
implementation saves a developer many hours of peril-prone labor. If
your "Bag" *is-a* HashMap with additional properties, you'd be fool to
re-invent the collection behaviors, and Sun would be Satan to withhold
the ability to extend the class.

This is magnified a gazillion times if you need to recreate collections
in the world of Java 1.5 generics.

So consider the technical merits of "just plain fugly" instead of
thoughtlessly resorting to rhetorical device. Nothing is "fuglier" than
having to reinvent such a complex, highly-engineered wheel as collection
classes. On the merits, making collections classes non-final is not
only a Good Thing, it's an utter necessity.



Relevant Pages


Loading