Why extend EventObject and EventListener

G

gerrards8

Exactly what are the benefits of extending EventObject and EventListener
for event delivery... Why not just use simple straight forward
interfaces. Something like:

public interface FruitBasketListener
{
public void applesAdded(int numberOfApples);
}

instead of

public class FruitBasketEvent extends EventObject
{
....
}

public interface FruitBasketListener extends EventListener
{
....
public void applesAdded(FruitBasketEvent evt);
....
}
 
P

Pete Barrett

Exactly what are the benefits of extending EventObject and EventListener
for event delivery... Why not just use simple straight forward
interfaces. Something like:

public interface FruitBasketListener
{
public void applesAdded(int numberOfApples);
}

instead of

public class FruitBasketEvent extends EventObject
{
...
}

public interface FruitBasketListener extends EventListener
{
...
public void applesAdded(FruitBasketEvent evt);
...
}

It's extensibility, I think. If you change that
applesAdded(FruitBasketEvent evt) to fruitAdded(FruitBasketEvent evt),
then the salient difference becomes more obvious - information about
the fruit being put in the basket is localised in the event, which
means that it's localised in the class that fires the event. The class
which consumes the FruitBasketEvent can examine the event and discard
any fruit it's not interested in.

That means that if you find you need to add oranges as well, the class
which implements FruitBasketListener won't need to be changed unless
it actually needs to do something with the oranges. In your first
example, if you added an orangesAdded method to the interface, it
would need change to implement that method, even if it did nothing
with it.

(Of course, you could define fruitAdded with the number and type of
fruit as parameters, but that quickly becomes unwieldy as the
information in the event increases.)

Having said that, if you know the inteface and its implementation will
only ever be private to a particular piece of code, there's no great
harm in doing it the first way. But a) do you really know that? and b)
if you do, is it necessary to use an interface at all?


Pete Barrett
 
T

Thomas Hawtin

It's extensibility, I think. If you change that
applesAdded(FruitBasketEvent evt) to fruitAdded(FruitBasketEvent evt),
then the salient difference becomes more obvious - information about
the fruit being put in the basket is localised in the event, which
means that it's localised in the class that fires the event. The class
which consumes the FruitBasketEvent can examine the event and discard
any fruit it's not interested in.

There are a number of other reasons.

It allows you to to write code with greater type-safety. You can write
code to deal with EventListener and EventObject, giving an indication of
what does what. For instance, javax.swing.EventListenerList.getListeners
will return an array, but the component type of that array must extend
EventListener. This doesn't necessarily give you complete type safety,
but does provide an indication of what is going on.

It also helps with bean and tool support. You have marked intention in
an unambiguous way.

Tom Hawtin
 
G

gerrards8

Thomas said:
There are a number of other reasons.

It allows you to to write code with greater type-safety. You can write
code to deal with EventListener and EventObject, giving an indication of
what does what. For instance, javax.swing.EventListenerList.getListeners
will return an array, but the component type of that array must extend
EventListener. This doesn't necessarily give you complete type safety,
but does provide an indication of what is going on.

It also helps with bean and tool support. You have marked intention in
an unambiguous way.

Tom Hawtin

Thank you both for replying. Your points are right on, but...

Reason I posed the question is the tremendous amount of code that's
involved in implementing this pattern. Whether for simple or complex
type MVC notifications (model to view), it results in too many
EventObject type classes (with their listeners and adapters, and of
course the add/removeXXXListener methods for each type of event in the
model) or a few (most of the times, a single) EventObject type classes
that are more complex than the model itsself.

The pattern does work very well in AWT & Swing type MVC patterns, but
its benefits quickly disappear when it's utilized in simple or even
complex business specific models.

Your thoughts?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top