commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject [collections] Refactoring decorators
Date Sat, 26 Apr 2003 13:39:09 GMT
Following a recent thread
I have been thinking about how to best structure the decorators in

Problems currently are:
- low visibility of a large amount of useful functionality
- increasing use being made of decorators (cf OrderedSet and ObservableList
currently waiting)
- inability for inner class design to cope with growth as easily as a broken
out design

I have started some work on a refactored design which comes out much
cleaner. The new design basically moves the inner classes into a subpackage
of their own 'decorators'.


Each class will have a static create() method on it to create the instance.
This is needed as it gives us flexibility to add new implementations in the
future that are switched dynamically using instanceof. IteratorUtils already
does this to ensure that the ResetableIterator interface is not lost by

Thus instead of:
  Bag bag = BagUtils.unmodifiableBag(bag);
you get
  Bag bag = UnmodifiableBag.create(bag);
(we could offer users a choice or deprecate the original)

A separate subpackage is most appropriate here as they work in a distinct
and different way to other collections, such as the constructor taking a
collection wraps and doesn't copy.

The main disadvantage is that it increases the public API, because the
classes are now public instead of private inner classes. But I'm sure
someone in OSS land will find this useful.

Looking at it and the continuing RFEs, some kind of change is needed, and
soon. Any objections?


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

View raw message