What is the common way to program action listeners?

Question

I just started to learn how to use action listeners. To my understanding it works in the following way:

1. There are some classes which contains \"addActionLis

Answer 1

Personnaly, when possible, i prefer to use an Action class (as an example a subclass of AbstractAction) instead of simply relying on an action listener. This way, I can provide the originating widget a name, an icon, a tooltip, and so on ...

Answer 2

The most common way to handle this - judging from my own personal experience - is to simply create an anonymous inline class. Like this:

listenedObject.addActionListener(new ActionListener() {
    @Override
    public void actionPerformed(ActionEvent evt) {
        // Your action handling code in here
    }
});

And often I've seen people place a call out to a method of the object containing the listenedObject. For example, in a Dialog that has a button:

myOkayButton.addActionListener(new ActionListener() {
    @Override
    public void actionPerformed(ActionEvent evt) {
        okayButtonPressed();
    }
});

Then later in the dialog class:

private void okayButtonPressed() {
    // Do what we need to do
}

Answer 3

Maybe it's not actually at the moment, but I believe that in the nearest future (after Java 7 release) something like this would be the common way:

listenedObject.addActionListener ( #{doSmth();} );

Answer 4

Beware that methods removeActionListener exists for a reason. You can skip listeners clean up if objects you listen to will die with object that handles events. But if your component listens the model supplied from external source, you should add your listeners in addNotify and remove them in removeNotify methods. Otherwise you may have a memore leak.

Answer 5

The way I have always found useful is to create a separate class which implements the ActionListener interface and all the other methods necessary to carry the action. This way, an action is not tied to a specific object and can be triggered from a button, a menu, etc. A little bit like the Command pattern I guess. It keeps the code simple.

Anonymous classes aren't reusable.

Redirection to the object containing the listenedObject leads to gigantic classes that are hard to maintain.

Answer 6

The way I have always found useful (for navigation purposes) is to create an anonymous inner class which then delegates to the outer class:

listenedObject.addActionListener(new ActionListener() {
    @Override
    public void actionPerformed(ActionEvent evt) {
        listenedObject_actionPerformed(evt);
    }
});


private void listenedObject_actionPerformed(ActionEvent evt) {
    //Your handling goes here
}

It is then much easier to get to your handling code in an IDE using a structural lookup (CTRL+F12 in IDEA, CTRL+O in Eclipse).

The problem of using a single class (like a GUI MyCoolPanel) as the common listener to a bunch of its components (buttons etc) is that the actionPerformed method then has a lot of ugly if-else comparisons to figure out which button has actually been pressed - not very OO at all!

You certainly should not get overly worried about the performance aspects of this kind of thing - they are likely to be negligible in the extreme! Premature optimization is famously a bad thing