Event source base class?

[Jeffrey Schwab]

Every time I write a class that's an event source, I give it a private
list of event listeners, add/removeListener methods, etc. What's the
better way to maintain a list of listeners? I could use
javax.swing.event.EventListenerList, but it has significant
shortcomings:

- The javadocs do not specify what happens when a listener is
added or removed multiple times.

- Proper use of EventListenerList requires a fair amount of
boilerplate code.

- It feels a little sketchy to use a Swing utility class when
I'm not using any other Swing components.

What do you consider best practice, and what are the most reasonable
alternatives?

 

[puzzlecracker]

Every time I write a class that's an event source, I give it a private
list of event listeners, add/removeListener methods, etc. What's the
better way to maintain a list of listeners? I could use
javax.swing.event.EventListenerList, but it has significant
shortcomings:

- The javadocs do not specify what happens when a listener is
added or removed multiple times.

- Proper use of EventListenerList requires a fair amount of
boilerplate code.

- It feels a little sketchy to use a Swing utility class when
I'm not using any other Swing components.

What do you consider best practice, and what are the most reasonable
alternatives?

You shouldn't use swing utility classes if you're not writing gui apps.
For ones, they are tuned for graphics but suffer a poor execution +
space performance in regular applications because of copious use of
synchronization coupled with large buffers.

EvenListenere is fairly common problem with a straightforward,
implementable solution. I suggest you code your own, targeting your
needs.


You should follow this inteface:

interface EventManger{
add(Listener l);
remove( Listener l);
subscribe(Listener l, Even e);
unSubscribe(Listener l,Even e);
...
}

Let me know if this helps or/and you need more information.

cracker....

 

[Nick Vatamaniuc]

Swing's way of doing things is pretty simple. But if you don't want to
have to import it and are worried about other 'behind the scenes' stuff
that might go on, just whip up your own event model. If you want to
talk about patterns what you would do is implement the 'observer'
pattern or to make the objects even more decoupled from each other you
would use the 'mediator' pattern.

Here is a short tutorial on the 'observer' pattern with some samples of
code:
http://www.javaworld.com/javaworld/javaqa/2001-05/04-qa-0525-observer.html

Here is a more abstract discussion of it:
http://en.wikipedia.org/wiki/Observer_pattern

Here is my quick explanation of it:
The idea is that there is a 'subject' say a linked-list model, and
there is an observer/ listener, for example some GUI, that wants to
_observe_ the linked list and know when it will be changed so it can
update it's GUI representation.

What happens is that the 'subject' (linked-list model) will have to
have a list of all the observers/listeners and when it changes, it will
notify them of that change. That is the basic dynamics here. Now, of
course the observers/listeners will have to let the subject know about
themselves. So they will have to _register_ with it to begin with. It
just means that they need to ask the subject to add them to its
observers/listerns list.

If you want to decouple the subject and obserers/listeners as much as
possible you can have an intermediate object that will be in charge of
receiving and dispatching events. Both subjects and observers/listeners
will have to register with it. This is called the 'mediator' pattern.

Here is an example:
http://en.wikipedia.org/wiki/Mediator_pattern

Hope this helps,
Nick Vatamaniuc

 

[Thomas Hawtin]

Every time I write a class that's an event source, I give it a private
list of event listeners, add/removeListener methods, etc. What's the
better way to maintain a list of listeners? I could use
javax.swing.event.EventListenerList, but it has significant
shortcomings:

- The javadocs do not specify what happens when a listener is
added or removed multiple times.

All the more reason not to do your own thing!

- Proper use of EventListenerList requires a fair amount of
boilerplate code.

Not much in comparison to creating a new event. And you only actually
have to do it once per event method. For most purposes
PropertyChangeEvent or ChangeEvent suffice.

The example in the API docs can also be simplified at the cost of a
little performance:

private void fireFooXXX() {
for (
FooListener listener :
listenerList.getListeners(FooListener.class)
) {
listener.fooXXX(new FooEvent());
}
}

(getListeners reverses the returned array...)

- It feels a little sketchy to use a Swing utility class when
I'm not using any other Swing components.

It's only there by historical accident. Java's packages are all over the
shop. Think of it as being in java.beans.

Tom Hawtin