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 Tue, 29 Apr 2003 21:44:54 GMT
I've just basically extracted the inner classes from the XxxUtils classes
and added a decorate() static method. The Collection and List ones are
checked in if anyone wants to check them out.

There are no unit tests, as I don't think we really had them before. And I
haven't removed the inner classes just yet either.

It would be good if someone could sanity check the classes created so far...

Stephen

----- Original Message -----
From: "Henri Yandell" <bayard@generationjava.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Monday, April 28, 2003 11:29 PM
Subject: Re: [collections] Refactoring decorators


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


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