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, and 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?
In Java, it is possible to define a class within another class, such classes are known as nested classes. They enable you to logically group classes that are only used in one place, thus this increases the use of encapsulation, and creates more readable and maintainable code.
And the benefit of it is you can have less number of objects created at runtime which wouldn't be the case with other types of nested classes. Disadvantage The only disadvantage I can think of is a static nested class has access to both the protected and private members of the outer class.
Nested Classes in C++ A nested class is a class which is declared in another enclosing class. A nested class is a member and as such has the same access rights as any other member. The members of an enclosing class have no special access to members of a nested class; the usual access rules shall be obeyed.
Nested Class can be used whenever you want to create more than once instance of the class or whenever you want to make that type more available. Nested Class increases the encapsulations as well as it will lead to more readable and maintainable code.
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 love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With