Cruel intentions

Thread view:

biffta@hotmail.com - 14 Jun 2005 23:33 GMT

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

Reply to this Message

Lucy - 14 Jun 2005 23:38 GMT

> 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
[quoted text clipped - 9 lines]
>
> Answers to this post could potentially shape the rest of my career!!!

Maybe you should check out C# just to be sure.

Reply to this Message

Paul Tomblin - 15 Jun 2005 01:13 GMT

In a previous article, biffta@hotmail.com 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.

Signature

Paul Tomblin <ptomblin@xcski.com> http://xcski.com/blogs/pt/
"Posting at the top because that's where the cursor happens to be is like
sh.tting in your pants because that's where your a.shole happened to be."
- Andreas Prilop takes OE top posters to task.

Reply to this Message

Larry Barowski - 15 Jun 2005 02:51 GMT

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.

Reply to this Message

SMC - 15 Jun 2005 07:47 GMT

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

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*

Signature

Sean

There's no place like 127.0.0.1

Reply to this Message

biffta@hotmail.com - 15 Jun 2005 10:10 GMT

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!

Reply to this Message

Larry Barowski - 15 Jun 2005 20:31 GMT

> The general consensus seems to be that separating the listener into
> another class is the way forward; whether it is an inner, anonymous or
[quoted text clipped - 13 lines]
> 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.

Reply to this Message

biffta@hotmail.com - 16 Jun 2005 11:24 GMT

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.

Reply to this Message

Larry Barowski - 16 Jun 2005 16:53 GMT

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

Reply to this Message

"." - 16 Jun 2005 15:50 GMT

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

Signature

Send e-mail to: darrell dot grainger at utoronto dot ca

Reply to this Message

George Cherry - 15 Jun 2005 20:02 GMT

> On Wed, 15 Jun 2005 08:33:04 +1000, biffta wrote:
>
[quoted text clipped - 15 lines]
> 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.

Reply to this Message

Cruel intentions

Free Magazines