🚀 go-pugleaf

Thanks for the info, John.  I wasn't aware of the benefits of using the
Event approach.  I'll have another option now.


Tim

"John McGrath [TeamB]" <ng-b@JPMcGrath.net> wrote in message
news:MPG.15a34a4bc155b44d98a2e4@forums.borland.com...
> 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