commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rich Dougherty" <>
Subject Re: [collections] [patch] NodeCachingLinkedList
Date Sat, 14 Dec 2002 10:19:32 GMT
> Thanks, although I'm a little confused ;-)
> What benefit does CommonsLinkedList give? A NodeCachingLinkedList class
> is allowed to subclass LinkedList directly. The licencing issue was that
> some of the methods in NodeCachingLinkedList were copied verbatim,
> especially noted in the javadoc. A reimplementation of
> NodeCachingLinkedList that directly extends LinkedList would be fine
> (written solely from the spec/idea, no copied code), unless
> CommonsLinkedList gives us something extra. I feel like I've missed
> something!

Good question. You're right that CommonsLinkedList doesn't really give
any extra benefit, at least in terms of features it offers. However, I
think it is nice in an OO sense, and it might be useful again in the

CommonsLinkedList is just another implementation of LinkedList,
except, perhaps, that it is a little easier to subclass than
LinkedList. This is a particularly useful for implementing
NodeCachingLinkedList. NodeCachingLinkedList extends
CommonsLinkedList. To implement caching it just overrides the
CommonLinkedList's node creation and node removal methods. By having
two classes I think we get a really nice separation of concerns: one
class knows about being a list, the other knows about caching. I think
that merging them together would result in a much messier
implementation. Just my opinion, of course. :-)

Another consideration is the fact that CommonsLinkedList might be a
nice class to use for future adaptions to LinkedList. The
standard LinkedList is pretty much opaque to subclasses. This is good
for a public API, but it makes it pretty difficult to
extend. CommonsLinkedList might be useful to keep around as a package
visible class.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message