commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Herve Quiroz <>
Subject Re: [events] DynamicProxy decorator
Date Tue, 20 Apr 2004 15:48:09 GMT

Here it is:

Basically, some classes or interfaces need to be renamed but I'll
refactor this another day:

-> "EventSource" should be "Observable"

I adopted a special event framework, or at least it is quite different
from the one you chose within [events]. Basically, I have one interface
for any event observer, called EventListener (just as in the standard
API). The only method is:

  public void processEvent(EventObject event);

You will note that I use a generic event class, also provided by the
standard API.

[ Damn! the site is broken... I can't have a look at [events] JavaDoc ]

I quite don't like when event identification is based on integers or
strings. I like to have them identified by their class or the interfaces
they implement. Maybe I'm totally wrong here, so please tell me if you
disagree (and most of all, tell me why). Here we have:

 `- CollectionEvent
     `- CollectionIsNoLongerEmptyEvent

Hence, an event listener may process events from multiple sources (with
different classes) through one method: processEvent. Here is an example:

public void processEvent(EventObject event)
  if (event instanceof CollectionIsNoLongerEmptyEvent)
    System.out.println("Hum. I can get something from this collection");
  if (event instanceof UniverseHasCollapsedEVent)
    System.out.println("Hum. That does not sound good");

If you want to bundle extra information regarding the event (e.g. how
many elements were added at once), it is possible: you implement it in
your specific event class. Then by casting 'event', an event listener
may retrieve this information.

You'll see also that proxy deprecate the need of specific Observable
interface such as ObservableBuffer, ObservableSet, etc...

Well, that's it for now.


On Mon, Apr 19, 2004 at 08:19:27PM +0100, Stephen Colebourne wrote:
> 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

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

View raw message