Ventajas de las clases anidadas para los oyentes en GUI

Question

Para proyectos de tamaño decente, me han dicho que cuando tiene clases que amplían JPanels, la mejor práctica es utilizar clases anidadas para implementar los oyentes. Por ejemplo, podría tener una clase FactoryScreen que amplíe JPanel, y tenga una clase anidada FactoryScreenBrain que implemente todos los oyentes necesarios.

Nunca he podido obtener una buena explicación de los beneficios o desventajas específicos para encapsular mis clases de esta manera, y hasta ahora siempre he tenido clases que amplían JPanel e implementan oyentes. ¿Alguien puede proporcionarme alguna orientación sobre esto?

Answer 1

Tener clases internas para sus oyentes hace que el propósito de todos los oyentes sea muy claro. También a veces puede evitar muchas verificaciones a expensas de un poco más de codificación.

Si usted tiene un 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 
    } 

que es muy difícil de ver exactamente lo que está pasando en su actionPerformed porque maneja tantos eventos diferentes a la vez. Que tiene un 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 
     } 
    } 

Ahora bien, si el temporizador tiene un problema que se puede identificar fácilmente la clase con el problema.

Aún más importante, a gran escala, hace que su código sea más legible. Si alguien más quiere trabajar en esta clase y necesitan arreglar el manejo de eventos con el temporizador, no tienen que buscar en su ifs para encontrar la parte con la lógica del temporizador.

Answer 2

Creo que cualquier cosa es mejor que tener una clase que amplíe un Componente de oscilación e implemente un oyente, ya que da a la clase demasiadas responsabilidades dispares y crea una para los temidos oyentes de la placa de conmutación. Intento usar oyentes internos anónimos que invocan métodos de una clase de control separada. De esa forma, divido las responsabilidades y puedo probar más fácilmente los comportamientos de cada clase de forma aislada.

Buena pregunta, por cierto.

Answer 3

Si extiende un componente e implementa uno o más oyentes, es tentador agregar los oyentes en el constructor. Esto potencialmente expone una referencia a un objeto construido de manera incompleta, a veces llamado escaped this. Trabajar exclusivamente en EDT mitiga el riesgo; pero una clase interna anónima puede reducirlo aún más. Los problemas de la reflexión o indirect exposure permanecen.