commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [collections] Refactoring decorators
Date Mon, 28 Apr 2003 22:07:52 GMT
Anyone got any views on this, otherwise I'll just go ahead...

Stephen

----- Original Message -----
From: "Stephen Colebourne" <scolebourne@btopenworld.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Saturday, April 26, 2003 2:39 PM
Subject: [collections] Refactoring decorators


> 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