On 8/8/11 10:46 PM, Sébastien Brisard wrote:
> 2011/8/8 Phil Steitz <phil.ste...@gmail.com>:
>> +1 to the idea of using the Observer pattern; but -0 for
>> Observable.  I would favor defining Events and Listeners because a)
>> Observable is concrete, so effectively forces you to create an
>> Observable delegate
>>
> I'm not sure I understand. Components in java.awt also need to
> implement quite a few methods like addListener, fireEvent, and so on.
> Maybe we could write a DefaultObservable, which would implement most
> of the methods required by Observable, and could be inherited by some
> (probably not all, unfortunately) of the already implemented iterative
> algorithms ?

I was suggesting that we dispense with having anything inherit from
Observable and just define events and listeners, similarly to what
you find in the awt components, but also elsewhere like javax.sql or
javax.servlet (and I am sure lots of other places too).  Observable
just gives you hasChanged and a primitive, non-type-safe
notifyListeners.  To do proper event propagation you need to define
custom events anyway and register listeners, so unless all you need
to raise are "some state has changed" events (like what a GUI
presentation layer needs from the model in MVC), you are better off
implementing a proper event framework.  This does not have to be
heavyweight.  Just define

0) Event class(es) extending j.u.EventObject
1) a listener interface extending j.u.EventListener
2) implement addXxxListener, removeXxxListener and
fireInterstingEvent1...n in the class that you want to be observable
(i.e. source events)

Items 0) and 1) and most of 2) are going to be necessary anyway if
you want to propagate typesafe events.  All that you really save by
bringing in Observable is maintenance of the listener collection,
which is trivial.

<snip/>

> Browsing through the JavaDoc, I realized that o.a.c.m.ode has some
> event handling facilities. Is the implementer still around?

That would be Luc.

Phil
> Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to