«

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);
....
}

On Sun, 28 Aug 2005 21:21:59 -0400, ""
<> wrote:

>
>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

Pete Barrett wrote:
> On Sun, 28 Aug 2005 21:21:59 -0400, ""
> <> wrote:
>
>>Exactly what are the benefits of extending EventObject and EventListener
>>for event delivery... Why not just use simple straight forward
>>interfaces. Something like:

> 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
--
Unemployed English Java programmer
http://jroller.com/page/tackline/

Thomas Hawtin wrote:
> Pete Barrett wrote:
>
>> On Sun, 28 Aug 2005 21:21:59 -0400, ""
>> <> wrote:
>>
>>> Exactly what are the benefits of extending EventObject and
>>> EventListener for event delivery... Why not just use simple straight
>>> forward interfaces. Something like:
>
>
>> 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

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?