Advantages to Nested Classes For Listeners in GUIs

For decently sized projects I've been told that when you have classes extending JPanels that the best practice is to use nested classes to implement the listeners. For example I could have a class FactoryScreen that extends JPanel, an开发者_StackOverflow中文版d have a nested class FactoryScreenBrain that implements all the necessary listeners.

I've never been able to get a good explanation for specific benefits or disadvantages to encapsulating my classes in this fashion, and until now have always just had classes that both extend JPanel and implement listeners. Can someone provide me some guidance on this?

---

Having inner classes for your listeners makes the purpose of all those listeners very clear. It can also sometimes avoid many if checks at the expense of a bit more coding.

If you have a panel

public class MyPanel extends JPanel implements ActionListener
...
    button1.addActionListener(this);
    button2.addActionListener(this);
    checkbox1.addActionListener(this);
    timer3.addActionListener(this);

    public void actionPerformed(ActionEvent e)
    {
        if(e.getSource() == button1)
        else...
        ... //potentially many elses
    }

it's very difficult to see exactly what is going on in your actionPerformed because it handles so many different events at once. Having a panel:

public class MyPanel extends JPanel
...
    button1.addActionListener(new ButtonListener());
    button2.addActionListener(new ButtonListener());
    checkbox1.addActionListener(new CheckBoxListener());
    timer3.addActionListener(new TimerListener());

    private class TimerListener implements ActionListener
    {
        public void actionPerformed(ActionEvent e)
        {
            //do stuff related only to timers
        }
    }

Now if your timer has an issue you can easily identify the class with the problem.

Even more importantly, on the grand scale, it makes your code more readable. If somebody else wants to work on this class and they need to fix event handling with the timer, they don't have to search through your ifs to find the part with the timer logic.

---

I think that anything is better than having a class extend a Swing Component and implement a listener as it gives the class too much disparate responsibilities and sets one up for creating the dreaded switch-board listeners. I try to use anonymous inner listeners that call methods from a separate control class. That way I divide out the responsibilities and can more easily test the behaviors of each class in isolation.

Good question, by the way.

---

If you extend a component and implement one or more listeners, it's tempting to add the listener(s) in the constructor. This potentially exposes a reference to an incompletely constructed object—sometimes called an escaped this. Working exclusively on the EDT mitigates the risk; but an anonymous inner class can further reduce it. Problems from reflection or indirect exposure remain.