commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [events] DynamicProxy decorator
Date Mon, 19 Apr 2004 19:19:27 GMT
I always welcome the chance to look at some code ;-) I can't promise to
integrate it, as my time has been limited of late, but it may benefit
others. [events] is another project where there is a good idea, and
potential for reusable code, but it lacks committers other than me :-(


----- Original Message -----
From: "Herve Quiroz" <>
> I've realized that using standard decorator pattern usually makes the
> "additional" interfaces such as "BoundedCollection" go away in the
> process. This means for instance that the CollectionUtils.isFull()
> method can no longer use the isFull() method from the object.
> You can implement complex decorators to handle that but then each time
> you add a new interface to your package, you have to re-implement your
> decorators. This is quite not re-usable actually.
> Lately, I've implemented an ObservableCollection decorator that is based
> upon the dynamic proxy paradigm. With only a few lines of code, this
> implementation allows the following:
> Buffer buffer=new BoundedFifoBuffer();
> ObservableCollection observable=ObservableCollectionUtil.decorate(buffer);
> assert observable instanceof Buffer;
> assert observable instanceof BoundedCollection;
> ..where there is no statement regarding Buffer and/or BoundedCollection
> in the ObservableCollectionUtil source code.
> I thought I could share.
> I have the following available:
> - interface ObservableCollection
> - class ObservableCollectionUtil
> - test case ObservableCollectionTest
> So far, I have only one kind of event, CollectionIsNoLongerEmptyEvent,
> as it is the only one I needed for my own package. However, if you feel
> interested by my contribution, I can provide addtional events, or
> refactor my classes to match one of the existing event models from
> [events].
> I also need observable functors for my own code, so chances are I will
> implement them as well. Same goes here: if you're interested, please
> tell me so we can plan things in advance and I don't need to refactor
> the classes to donate them to Apache...
> Tell me if you want to have a look at the classes, and I will post a
> link on my homepage.
> Herve
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message