commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: [collections] Refactoring decorators
Date Mon, 28 Apr 2003 22:29:05 GMT

I'm +1 to the increased api, but mainly I'm +1 to an homogenous system.

Any chance of a document to describe the system, a list of all the
collections in Collections and a yay or nay as to whether they currently
fit the described system?

I'm happy to help migrate if I have a clue what the grand-scheme is :)

Hen

On Sat, 26 Apr 2003, Stephen Colebourne wrote:

> Following a recent thread
> http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg19523.html
> I have been thinking about how to best structure the decorators in
> [collections].
>
> 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'.
>
> o.a.c.c.decorators.AbstractCollectionDecorator
> o.a.c.c.decorators.PredicatedCollection
> o.a.c.c.decorators.UnmodifiableCollection
> o.a.c.c.decorators.SynchronizedBag
> o.a.c.c.decorators.UnmodifiableBag
> etc.
>
> 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
> decorating.
>
> 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?
>
> Stephen
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message