commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodney Waldhoff <rwaldh...@apache.org>
Subject Re: [collections] Refactoring decorators
Date Mon, 28 Apr 2003 22:22:11 GMT
+1 to moving any generally useful inner class within collections to a
plain old java class.

- Rod <http://radio.weblogs.com/0122027/>

On Mon, 28 Apr 2003, Stephen Colebourne wrote:

> 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
>
>
> > 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


Mime
View raw message