🚀 go-pugleaf

On Tue, 26 Jun 2001 07:43:32 -0700, Tim Dietz wrote:

> The AWTEvent class, which is the parallel component to the
> Observable class in this comparison is not an interface,
> either.  Why is it better?

I think the AWTEvent class (or its superclass, EventObject) is 
analogous to the second argument to the update() method in the
Observer interface.  There isn't a class or interface analogous
to the Observable class when you use the Event approach.  You
typically add Observers / Listeners by calling an addXxxListener() 
method, but these methods are not part of an interface.

> I also don't see how a generic AWTEvent class can differentiate
> between certain kinds of changes and an Observable class cannot.

Say we have an object (which I will call the source) that can have two 
different things happen to it that are of interest to the outside world 
(say Foo and Bar).  If we use the Observer / Observable approach, each 
interested object will add itself as an Observer to the source.  When a 
"Foo" happens, the source will notify all of its observers by sending 
it a Foo object.  So the Observer who is only interested in Bar will 
see the Foo.

If we use the Event approach, the source will have an addFooListener() 
method and an addBarListener().  The object interested in Foo will only 
add itself as a FooListener, so it will not see the BarEvents.

With the Observer approach, the Observer will typically test whether 
the second argument to the update() method is of the class that it is 
interested in, and then cast it to that class.  

The java.beans PropertyEvent handling code even takes this a little 
further.  This allows you to register a PropertyChangeListener to 
listen for changes of a single property or any property.

> I can see using the Event classes for graphical situations
> (which is what the original poster was asking about), but
> it just seems to me that if you're not in a graphical
> situation where you need an Observer pattern, the Observer/
> Observable classes fill the bill with less of a footprint.

There is nothing about Events that are in any way tied to graphical 
situations.  As I pointed out above, the AWTEvent class is derived from 
EventObject, and is a specialized event for use with the AWT GUI.

I am not sure why you think that there is less of a footprint when you 
use the Observable class.  The Observable class contains a boolean and 
a Vector reference, and the Vector is always allocated, whether or not 
there are any Observers.

With the event approach, the implementation is up to you.  It is fairly 
easy to imagine an implementation that uses just a single ArrayList, 
and does not actually allocate the ArrayList unless a listener is 
added.  Even if you use the EventListenerList class (which I normally 
use), you only have a single EventListenerList, and that contains just 
a single array of Objects.


However, IMO, the most important reason to use the Event approach is 
that it does not require you to subclass Observable.  When you can only 
have a single subclass in Java, it does not make a lot of sense to use 
it up for handling event/observer notification.

-- 
Regards,

John McGrath [TeamB]

---------------------------------------------------
Before sending me e-mail, please read:
    http://www.JPMcGrath.net/newsgroups/e-mail.html