Cruel intentions

B

biffta

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

Lucy

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

Paul Tomblin

In a previous article, (e-mail address removed) 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.
 
L

Larry Barowski

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

SMC

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

biffta

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

George Cherry

SMC said:
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.
 
L

Larry Barowski

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

biffta

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

.

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

Larry Barowski

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.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,905
Latest member
Kristy_Poole

Latest Threads

Top