🚀 go-pugleaf

"John McGrath [TeamB]" <ng-b@JPMcGrath.net> wrote in message
news:MPG.15a1edf02782756398a2de@forums.borland.com...
> On Mon, 25 Jun 2001 13:08:23 +0100, Steve Holt wrote:
>
> > Check out the Observer/Observable classes.
>
> The Observer interface and Observable class implement the Observer
> pattern, but so do the Event classes mentioned in the link that
> Torsten posted.  Either will work, but I think the Event approach
> is better.
>
> One reason is that Observable is a class, not an interface.  Since
> you must extend Observable, you cannot extend another class, which
> can be a significant problem.
>

I'm confused here.  The AWTEvent class, which is the parallel component
to the Observable class in this comparison is not an interface, either.  Why
is it better?

> Another problem is with the granularity of the notification.  With
> the Observer classes, every Observer is notified whenever there is
> any kind change in the Observable.  It is not possible to register
> as an Observer for only certain kinds of changes.  With the Event
> classes, you can do this.
>

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

> One final argument for the Event classes:  If you search the entire
> source for the Java core classes, you will not find a single use of
> Observer and Observable, but you will find thousands of uses of the
> Event classes.
>

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.


Just my ignorant $.02 worth.

Tim

> --
> Regards,
>
> John McGrath [TeamB]
>
> ---------------------------------------------------
> Before sending me e-mail, please read:
>     http://www.JPMcGrath.net/newsgroups/e-mail.html