commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
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 :-(

Stephen

----- Original Message -----
From: "Herve Quiroz" <herve.quiroz@esil.univ-mrs.fr>
> 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: 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