GUI中监听器的嵌套类的优点

对于体积适中的项目，我被告知当你有扩展JPanels的类时，最好的做法是使用嵌套类来实现监听器。 例如，我可以有一个扩展JPanel的类FactoryScreen，并有一个嵌套类FactoryScreenBrain，它实现了所有必要的监听器。

我从来没有能够以这种方式为我的类封装特定的好处或缺点得到一个很好的解释，直到现在总是只有扩展JPanel和实现监听器的类。 有人能为我提供一些指导吗？

Answer 1

为听众设置内部课程可以使所有听众的目的非常清晰。 如果以更多编码为代价进行检查，它有时也可以避免许多。

如果你有一个小组

 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 } 

很难确切地看到你的actionPerformed中发生了什么，因为它一次处理了很多不同的事件。 有一个小组：

 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 } } 

现在，如果您的计时器有问题，您可以轻松识别出有问题的class级。

更重要的是，在大规模上，它使您的代码更具可读性。 如果其他人想要在这个类上工作并且他们需要使用计时器修复事件处理，他们不必搜索你的ifs以找到具有计时器逻辑的部分。

Answer 2

我认为任何东西都比让一个类扩展一个Swing组件并实现一个监听器更好，因为它给了类太多不同的职责，并为创建可怕的交换板监听器设置了一个。 我尝试使用匿名内部侦听器从单独的控件类调用方法。 这样我就分出了责任，可以更容易地孤立地测试每个class级的行为。

顺便问一下好问题。

Answer 3

如果扩展组件并实现一个或多个侦听器，则很容易在构造函数中添加侦听器。 这可能会暴露对未完全构造的对象的引用 – 有时称为转义对象。 专门从事EDT工作可以降低风险; 但是一个匿名的内部类可以进一步减少它。 反思或间接曝光的问题仍然存在。