Cruel intentions

Discussion in 'Java' started by biffta@hotmail.com, Jun 14, 2005.

  1. Guest

    I am just starting to develop GUIs in java and have been reading "Big
    Java" by Cay Horsmann. I believe it to be quite a simple book but this
    is exactly what I need right now. One thing he suggests when it comes
    to event handlers is to define a separate (inner) class for them. And
    he states that implementing the ActionListener interface in the same
    class where you define your components is a bad idea.

    It seems to make sense in theory, but having looked through loads of
    examples on the Sun website they all do the exact opposite! Which leads
    me to wonder if this is one of those "good intentions" type ideas that
    no one really bothers with?

    Answers to this post could potentially shape the rest of my career!!!
     
    , Jun 14, 2005
    #1
    1. Advertising

  2. Lucy Guest

    <> wrote in message
    news:...
    > I am just starting to develop GUIs in java and have been reading "Big
    > Java" by Cay Horsmann. I believe it to be quite a simple book but this
    > is exactly what I need right now. One thing he suggests when it comes
    > to event handlers is to define a separate (inner) class for them. And
    > he states that implementing the ActionListener interface in the same
    > class where you define your components is a bad idea.
    >
    > It seems to make sense in theory, but having looked through loads of
    > examples on the Sun website they all do the exact opposite! Which leads
    > me to wonder if this is one of those "good intentions" type ideas that
    > no one really bothers with?
    >
    > Answers to this post could potentially shape the rest of my career!!!


    Maybe you should check out C# just to be sure.
     
    Lucy, Jun 14, 2005
    #2
    1. Advertising

  3. Paul Tomblin Guest

    In a previous article, said:
    >is exactly what I need right now. One thing he suggests when it comes
    >to event handlers is to define a separate (inner) class for them. And
    >he states that implementing the ActionListener interface in the same
    >class where you define your components is a bad idea.


    I don't know the theory, but I've developed my own in 20 years of
    maintaining my own and other people's code in everything from FORTRAN to
    Java. And 90% of what you read in books about maintainability is bull.

    To me, if what I'm doing with the ActionListener is small and quick,
    I'll do it with an anonymous class. If it's a bit bigger, or something
    where I want to use the same listener for several actions, I'll make a
    separate inner class. Or sometimes I'll have an anonymous class that
    calls a method in the outer class. If it's really big, I might make an
    external class to do it. There are no hard and fast rules specifying whe
    I use any of these methods, just what seems right at the time.

    Oh, and if the task gets really time consuming, you'll want it to be a
    separate class (inner or outer) so that it's easier to turn it into a
    Runnable and spawn off a separate thread to handle it.

    --
    Paul Tomblin <> http://xcski.com/blogs/pt/
    "Posting at the top because that's where the cursor happens to be is like
    shitting in your pants because that's where your asshole happened to be."
    - Andreas Prilop takes OE top posters to task.
     
    Paul Tomblin, Jun 15, 2005
    #3
  4. <> wrote in message
    news:...
    > I am just starting to develop GUIs in java and have been reading "Big
    > Java" by Cay Horsmann. I believe it to be quite a simple book but this
    > is exactly what I need right now. One thing he suggests when it comes
    > to event handlers is to define a separate (inner) class for them. And
    > he states that implementing the ActionListener interface in the same
    > class where you define your components is a bad idea.
    >
    > It seems to make sense in theory, but having looked through loads of
    > examples on the Sun website they all do the exact opposite! Which leads
    > me to wonder if this is one of those "good intentions" type ideas that
    > no one really bothers with?
    >
    > Answers to this post could potentially shape the rest of my career!!!


    If you expect your class to be subclassed, then implementing
    ActionListener (or any listener) at the class level can cause
    problems. If the subclass also does this, then it is now required
    to call your handler from the subclass handler, but only for
    events that aren't generated and handled in the subclass (since
    sending unexpected events to the superclass handler may break
    something). Some of the superclass events may look like events
    the subclass is expecting, and if the superclass is changed
    later so that this is so, this may break functionality in the
    subclass. The superclass and subclass may both need to handle
    some events, but this may change for either class in the future,
    and break things in one or the other. And of course, the
    developer of the subclass has to know all of this, figure it out
    when the thing breaks, or be smart enough not to use the class
    as a listener in the first place.

    If, on the other hand, your class is one that is unlikely to
    ever be subclassed, like an application or "main window"
    class, and if the implementer of the superclass didn't use
    the class as a listener, then it probably doesn't matter.
     
    Larry Barowski, Jun 15, 2005
    #4
  5. SMC Guest

    On Wed, 15 Jun 2005 08:33:04 +1000, biffta wrote:

    > I am just starting to develop GUIs in java and have been reading "Big
    > Java" by Cay Horsmann. I believe it to be quite a simple book but this
    > is exactly what I need right now. One thing he suggests when it comes to
    > event handlers is to define a separate (inner) class for them. And he
    > states that implementing the ActionListener interface in the same class
    > where you define your components is a bad idea.
    >
    > It seems to make sense in theory, but having looked through loads of
    > examples on the Sun website they all do the exact opposite! Which leads
    > me to wonder if this is one of those "good intentions" type ideas that
    > no one really bothers with?
    >
    > Answers to this post could potentially shape the rest of my career!!!


    You're putting the fate of your career in the hands of UseNet? That's
    like putting the fate of your country in the hands of George W. Bush
    (again even). *Ducks*

    --
    Sean

    There's no place like 127.0.0.1
     
    SMC, Jun 15, 2005
    #5
  6. Guest

    The general consensus seems to be that separating the listener into
    another class is the way forward; whether it is an inner, anonymous or
    completely separate class. However as Larry points out if the program
    in question is a main window then it really doesn't do much harm to
    have everything under one roof. This would support most of the examples
    on the Sun site.

    I do have a bit of a follow up question though, which is to do with
    Larry's concerns over subclassing from a class that implements an
    actionlistener. I don't completely follow the reasoning behind the
    problems but if we imagine we have a program that has several windows,
    all of which follow a template. You first create a generic frame which
    implements an actionlistener for a JMenu. Then you create lots of
    subclasses all which inherit from template, adding more specific
    functionality. Would this cause a problem? If the parent and child
    class were both on display at the same time and you were picking out
    menu items, would there be confusion in who reacted to the events? And
    what about the alternative; if you created the generic superclass with
    an inner class which dealt with events, would a subclass even be able
    to react to events at all, in other words are inner classes inherited?

    Thanks for the help chaps!
     
    , Jun 15, 2005
    #6
  7. "SMC" <> wrote in message
    news:p...
    > On Wed, 15 Jun 2005 08:33:04 +1000, biffta wrote:
    >
    >> I am just starting to develop GUIs in java and have been reading "Big
    >> Java" by Cay Horsmann. I believe it to be quite a simple book but this
    >> is exactly what I need right now. One thing he suggests when it comes to
    >> event handlers is to define a separate (inner) class for them. And he
    >> states that implementing the ActionListener interface in the same class
    >> where you define your components is a bad idea.
    >>
    >> It seems to make sense in theory, but having looked through loads of
    >> examples on the Sun website they all do the exact opposite! Which leads
    >> me to wonder if this is one of those "good intentions" type ideas that
    >> no one really bothers with?
    >>
    >> Answers to this post could potentially shape the rest of my career!!!

    >
    > You're putting the fate of your career in the hands of UseNet? That's
    > like putting the fate of your country in the hands of George W. Bush
    > (again even). *Ducks*


    No, no. There's some wisdom in usenet,
    but none in George W. Bush. Therefore,
    there's no comparison.
     
    George Cherry, Jun 15, 2005
    #7
  8. <> wrote in message
    news:...
    > The general consensus seems to be that separating the listener into
    > another class is the way forward; whether it is an inner, anonymous or
    > completely separate class. However as Larry points out if the program
    > in question is a main window then it really doesn't do much harm to
    > have everything under one roof. This would support most of the examples
    > on the Sun site.
    >
    > I do have a bit of a follow up question though, which is to do with
    > Larry's concerns over subclassing from a class that implements an
    > actionlistener. I don't completely follow the reasoning behind the
    > problems but if we imagine we have a program that has several windows,
    > all of which follow a template. You first create a generic frame which
    > implements an actionlistener for a JMenu. Then you create lots of
    > subclasses all which inherit from template, adding more specific
    > functionality. Would this cause a problem? If the parent and child
    > class were both on display at the same time and you were picking out
    > menu items, would there be confusion in who reacted to the events?


    There is no problem at run time as long as everything is done
    correctly. The problem is in development. If both the superclass
    and subclass handle events from the action listener, then changes
    to the superclass handler may require changes to the subclass
    handler, and will at least require close examination to ensure that
    no problems are introduced. Just calling the superclass handler
    from the subclass handler is not enough. Even if one developer
    will always be responsible for both classes, this may lead to
    mistakes. If the superclass is part of a library, this is a probable
    disaster, as upgrading the library, with no changes to the API,
    may break an application in very confusing ways. It would also
    require very comprehensive documentation of exactly what the
    superclass handler does (the source code would probably be the
    only adequate documentation), and extreme care when
    implementing the handler in the subclass.

    > And
    > what about the alternative; if you created the generic superclass with
    > an inner class which dealt with events, would a subclass even be able
    > to react to events at all, in other words are inner classes inherited?


    You can subclass the inner handler class, but this would cause
    the same problem. If a superclass needs a subclass to handle
    particular events or needs to allow this, it should do this in some
    other way, such as providing a specific method or methods
    (possibly abstract) apart from the handler, or allowing listeners
    for those particular events to be added to it. Otherwise, the
    subclass should just register its own handlers where necessary.
     
    Larry Barowski, Jun 15, 2005
    #8
  9. Guest

    I am now most certainly confused! To me the whole advantage of OOP is
    code reuse, but from what I have read it seems that even trying to
    reuse an event handler for a JMenu is less than trival. If you make a
    change to the superclass e.g. add a new item on the help menu, you must
    go through and thoroughly test every subclass?

    The alternitve as Larry suggests is to use a specific (abstract) method
    to react to events, which confuses me further!

    Sorry, I want to make sure I get this right from the beginning and am
    finding it difficult to get my head round.
     
    , Jun 16, 2005
    #9
  10. . Guest

    On Wed, 15 Jun 2005 wrote:

    > The general consensus seems to be that separating the listener into
    > another class is the way forward; whether it is an inner, anonymous or
    > completely separate class. However as Larry points out if the program
    > in question is a main window then it really doesn't do much harm to
    > have everything under one roof. This would support most of the examples
    > on the Sun site.


    I learned Java when it first came out. All the books at that time agreed
    with the author you are currently reading. In 1998 I moved into a job that
    was as far removed from Java as you could possibly get (assembly language
    and embedded programming). Last year I changed companies and I'm now back
    into programming Java. I picked up a new book and was shocked to see it
    recommending the use of anonymous inner classes for things like Threads
    and ActionListeners. At first it threw me. It has been a year now and I
    find that it makes the code easier to read and maintain now that I am
    writing code like the examples you found on the Sun web site.

    Maybe your book is just dated? Regardless, over the years I have found
    that there is no one right style. You just have to go with what fits and
    be willing to change if necessary. As the saying goes, "When in Rome, do
    as the Romans do."

    --
    Send e-mail to: darrell dot grainger at utoronto dot ca
     
    ., Jun 16, 2005
    #10
  11. <> wrote in message
    news:...
    > I am now most certainly confused! To me the whole advantage of OOP is
    > code reuse, but from what I have read it seems that even trying to
    > reuse an event handler for a JMenu is less than trival. If you make a
    > change to the superclass e.g. add a new item on the help menu, you must
    > go through and thoroughly test every subclass?


    But there is almost always no good reason to reuse an event
    handler. Superclasses and subclasses should handle events
    separately. Note that the Swing component classes rarely
    implement ActionListener. JComboBox does, but you'll see
    the comment "This method is public as an implementation
    side effect. do not call or override."

    > The alternitve as Larry suggests is to use a specific (abstract) method
    > to react to events, which confuses me further!


    You would only make it abstract if subclassing is necessary
    and the subclass "must" react to the event. More commonly,
    you would allow listeners (your own class of listeners) to be
    added to the parent. Either way, this allows the superclass to
    change the internals of how these events are generated
    without breaking subclasses.
     
    Larry Barowski, Jun 16, 2005
    #11
    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. Woolly Mittens
    Replies:
    3
    Views:
    341
Loading...

Share This Page