Java - Should ActionListeners, KeyListeners, Etc, Always Be Declared In Inner Classes?

Question

Hi coders,

In all the Java source code examples I have looked at the listeners have always been declared in inner classes.

Why - what is the reason for coding the classes like this instead of having the listener(s) in their own seperate *.java file \ class?

Would having seperate classes for the listeners be considered a bad design?

If it's not a bad design \ sackable offence could someone please post a short example demonstrating how to implement this?

Thank for reading.

Edit\Update - 10.8.2010: Thanks to all who took the time to reply. Lots of insightful points to consider. Having read all the answers I think that unless there is a very good reason for doing otherwise it is better and easier to declare listeners as inner classes.

Apologies for not coming back to this question sooner, but I don't always have as much time for coding as I'd like :-(

Happy coding.

Answer 1

If you've seen them in examples its probably to make it seem easier. Most will probably tell you to just take your current class and implement the listener. Which one looks easier: Creating 2 classes in 2 files, using a nested listener inside of a main class, or just having your main class as the listener? (Hint: Its not the first one)

I'm lazy and just have a main class implement the ActionListener interface. This of course only works on very simple GUIs. For larger projects you should separate them.

As for keeping the Listener in a separate class, ask yourself: Do other classes need to use this? Classes should be in their own file ONLY if others need to use them. And sharing Listeners isn't exactly the best idea unless you have some weird layout where buttons do the same thing but are arranged differently by each class.

In short: keep them nested or implemented, not separate, unless necessary. A necessary case however would be few and far between

Answer 2

Good reasons for using inner classes:

• Avoids adding extra top-level classes to your package namespace
• Keeps the code locally encapsulated (e.g. within the component that requires the event handling behaviour)
• static inner classes work well when they do not need to access fields of the enclosing class

Possible reasons for using top level classes:

• You have a special type of listener that you expect to be used by external packages or forms part of your API (e.g. in the Java class library itself)
• The listener is used in many places, and is not logically specific to any one of many possible enclosing classes

In short: inner classes are usually preferred, but if you have good reasons then it can be perfectly sensible to create top level classes instead.

Answer 3

You certainly could have the listener implemented in a separate class file in a separate .java file. Java 1.1 introduced the anonymous class and inner class idea along with awt event redesign years ago. The reason is that many times, the listeners that you write need to update and/or read fields from the class that contains the objects where events are generated. It is cumbersome to referense these fields from a non inner/anonymous class.

Once you use anonymous classes more, you will see that it does make things simpler to write and maintain later. Modern IDE's will even generate most of the code for you anyway. For example, key in these two lines in IntelliJ IDEA and press ctrl-shift-space. IntellJ will insert an anonymous class that impmlements all methods of the interface specified by addActionListener().

JButton jb = new JButton("ok");
jb.addActionListener(new 

Answer 4

An inner class is local to the current class, which is fine in case those do not need to be used elsewhere. In an example in a book it gives the class a name which makes it possible to refer to it easily from prose.

The typical usage for listeners is that they are only used in a single place and for that purpose the anonymous inner classes are perfect. For interfaces with a lot of method (like MouseListeners) there is usually a corresponding adapter with empty implementations of everything which can then be overridden as needed. See MouseAdapter.

Answer 5

No, I don't think they should always be inner classes. It implies that the UI itself always knows how to make the best choice of listener.

Another way to look at it might be that Listeners are injected into the UI. Maybe they're provided by the Controller, which instantiates the UI and tells it how to react to UI events.

I think this is more of a dependency injection view of the world. There may be important advantages to it.

Answer 6

This answer discusses the trade offs of the different ways.

The basic answer is that the GUI code in a program is usually pretty intertwined and not usually shareable between programs. Doing inner classes (especially if you adopt the way I suggest in the linked answer above) lets you structure the GUI code so that it is maintainable while accepting that the GUI is highly coupled.