tags:

views:

50

answers:

4

Which are, for every of the following methodology to implement an interface listeners, the pros and cons:

1) into the main class as:

class MyClass implements ActionListener {
    public void actionPerformed(ActionEvent e) {
        // ...
    }

    component.addActionListener(this);
}

2) as an inner class as

class MyClass {
    private class MyActionListener implements ActionListener {
        public void actionPerformed(ActionEvent e) {
            // ...
        }
    }

    MyActionListener mal = new MyActionListener();
    component.addActionListener(mal);
}

3) as an anonymous inner class as

class MyClass {
    component.addActionListener(new ActionListener() {
        public void actionPerformed(ActionEvent e) {
            // ...
        }
    });
}
A: 

An anonymous inner class (3) can only be used for one component and I normaly use this to delegate to a protected method in the outer class without the Event parameter.

(1) and (2) allows to reuse the Listener instance for multiple components but then one needs to find out via the Event object the source component.

So it's up to the task to pick between (1)/(2) or (3).

Greetz, GHad

GHad
Nonsense. [chars]
Tom Hawtin - tackline
Thank you Tom Hawtin for the detailed explanation. It was a pleasure to learn from your wisdom
GHad
A: 

If your main class doesn't have some reason for exposing ActionListener functionality outside of itself, then it's an implementation detail and you don't want to go with #1. #1 locks you into providing that interface.

You'll see a lot of #3, but I have never been a fan. If you do that, you can't reuse that ActionListener implementation anywhere else.

For that reason, I'd go either with #2 or with the one you didn't mention, which is making a package-level class that does the implementation (which allows you to reuse it elsewhere).

T.J. Crowder
+1  A: 

Implementing callback interfaces to existing classes is pure evil. Obviously. Just don't do it. Ever.

Non-local inner classes are a bit on the pointless side. You can use them with inheritance, they can have multiple constructors, they do have a name, etc. If you have those sort of requirements, then you really should be looking new outer classes.

Anonymous inner classes are relatively concise. They remove the need to add fields and constructors to copy fields. The temptation some people feel to make local variables fields in the "main" class vanishes. You can just make local variables from the enclosing method final. "Reuse" can be achieved through bog standard programming, without having to resort to introducing more named classes.

Tom Hawtin - tackline
A: 

In addition to the issues of interface and re-use mentioned by others, consider readability. The third can reduce readability if the implementation of actionPerformed() is long.

Also, #2 allows your inner class to have a constructor with arguments, and include fields, should those not already be available from the containing top-level class.

Andy Thomas-Cramer