Re: Custom Listeners, yes, but why custom Events?
Leo Breebaart writes:
Am I missing some very obvious advantage to the FooEvent
approach?
(Stefan Ram) wrote:
Posted events get queued in the time-ordered event queue,
while e direct call might be out of order.
When Swing calls a listener, the listener can be sure to
run in the EDT, which is not obvious, when a listener is
called directly.
A GUI object usually accepts an arbitrary number of
listeners for certain kinds of events at run-time and then
notifies them of the events. This can not be accomplished
with hard-coded calls of specific methods. The binding is
more loose with events than with calls.
Swing might merge certain events in the event queue into
a single event IIRC, so posted events are not mapped 1:1
to calls of event listeners.
Other event processors might possibly be added, such as
macro recorders / macro replayers. They will only record
events, but miss direct calls.
Those were just things that immediatly came into my mind,
I might have missed others.
John B. Matthews wrote:
This comports with my understanding. Using the approach described
in the API for EventListenerList offers additional benefits:
<http://java.sun.com/javase/6/docs/api/javax/swing/event/EventListenerList.html>
In addition to those mentioned, the use of a type-token (e.g.
FooListener.class) affords an opportunity for type checking.
In addition to what these fine folks have said, that all Events are in the
same type hierarchy is a boon. Event handlers are only tied to the event
type, so generalized mechanisms can deal with event delivery and processing
without regard for the specifics, unlike if different-typed objects were
passed around. Futhermore, events can carry semantics (attributes and
behavioral methods) that are tuned to the event aspect, which, of course,
domain objects should not do.
--
Lew