Why extend EventObject and EventListener

Discussion in 'Java' started by gerrards8@yahoo.com, Aug 29, 2005.

  1. Guest

    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);
    ....
    }
     
    , Aug 29, 2005
    #1
    1. Advertising

  2. Pete Barrett Guest

    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, Aug 29, 2005
    #2
    1. Advertising

  3. 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, Aug 29, 2005
    #3
  4. Guest

    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?
     
    , Aug 29, 2005
    #4
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Michael Holtermann
    Replies:
    0
    Views:
    670
    Michael Holtermann
    Sep 9, 2003
  2. Michael Holtermann
    Replies:
    0
    Views:
    381
    Michael Holtermann
    Sep 15, 2003
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,270
    Smokey Grindel
    Dec 2, 2006
  4. Replies:
    1
    Views:
    344
    Daniel Pitts
    Feb 2, 2007
  5. mj
    Replies:
    0
    Views:
    120
Loading...

Share This Page