Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Why extend EventObject and EventListener

Reply
Thread Tools

Why extend EventObject and EventListener

 
 
gerrards8@yahoo.com
Guest
Posts: n/a
 
      08-29-2005

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

 
Reply With Quote
 
 
 
 
Pete Barrett
Guest
Posts: n/a
 
      08-29-2005
On Sun, 28 Aug 2005 21:21:59 -0400, "(E-Mail Removed)"
<(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Thomas Hawtin
Guest
Posts: n/a
 
      08-29-2005
Pete Barrett wrote:
> On Sun, 28 Aug 2005 21:21:59 -0400, "(E-Mail Removed)"
> <(E-Mail Removed)> 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/
 
Reply With Quote
 
gerrards8@yahoo.com
Guest
Posts: n/a
 
      08-29-2005
Thomas Hawtin wrote:
> Pete Barrett wrote:
>
>> On Sun, 28 Aug 2005 21:21:59 -0400, "(E-Mail Removed)"
>> <(E-Mail Removed)> 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?
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ActionEvent / EventListener in a web app? rschmid-google@raptor.net Java 1 02-02-2007 06:18 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
Add and remove Object as EventListener mj Javascript 0 06-02-2006 03:05 PM
Re: [XML][SVG]How to add an EventListener to every element? Michael Holtermann Java 0 09-15-2003 09:07 AM
[XML][SVG]How to add an EventListener to every element? Michael Holtermann Java 0 09-09-2003 12:30 PM



Advertisments