Re: [computer-go] Event-driven programming

[Peter Drake <drake@xxxxxxxxxx>]

On Friday, January 16, 2004, at 01:36  AM, Patrick Stiegeler wrote:

> dear peter,
>
> i think, i did something like what you call "event-driven programming".
> i use a singleton which i call a NotificationServer and which handles 
> all
> the message passing:
So  you only have a single NotificationServer?  How do you determine 
which listeners get which events ... or do you just send every event to 
all listeners in the entire system?

> so if object A wants to report an event it calls...
>
> 	NotificationServer.instance().notifyEvent( this, "some message" );
>
> 	note: i include a reference to the sending object (this), so that
> 	      a receiving object may talk to the sending object, if
> 	      nescessary
>
> ...and if object B wants to get notified by an event, it calls the
> following on startup (e.g.):
>
> 	NotificationServer.instance().addListener( this, "some message" );
>
> Then, if the NotifificationServer gets a notifyEvent() message, it 
> works
> its list of listeners and calls their worldChanged() method or whatever
> you like to name it in your definition of the listener interface.
I've got a clever scheme whereby a class can have a factory which 
watches some other class and is informed whenever an instance of that 
class is created.  More poking around is needed.

> i think, this kind of programming addresses well the problem, that
> this "who is gonna talk to whom?" stuff is often independent from
> the "this object is a part of this object" assembling in object 
> oriented
> programming.
> you don't have to pass around each objects reference to get the right
> objects talk to each other. just have your NotificationServer available
> in the classpath...
>
> i hope, this helps you a bit...
Yes, it does.  If you have any papers on this, I'd love to see URLs.

> btw: i would call this "event-driven programming", too.
>      in the real world ;) there are many examples of
>      different subject areas having different notions of
>      the same word.
When I realized that an event server of some kind would be necessary, I 
thought this might be closer to event-driven.  It doesn't exactly sit 
and wait for events, but it does keep asking, "What's the next event in 
the queue?"

Peter Drake
Assistant Professor of Computer Science
Lewis & Clark College
http://www.lclark.edu/~drake/

_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://computer-go.org/mailman/listinfo/computer-go