2010-04-26 27 views
7

Tanto en mis clases de Java como en los libros que usamos en ellas, se diseñó una GUI con código que implicó fuertemente al constructor de JFrame. La técnica estándar en los libros parece ser inicializar todos los componentes y agregarlos al JFrame en el constructor, y agregar controladores de eventos anónimos para manejar los eventos cuando sea necesario, y esto es lo que se ha recomendado en mi clase.¿Mejores prácticas con JFrame Constructors?

Esto parece ser bastante fácil de entender, y fácil de usar cuando se crea una GUI muy simple, pero parece volverse rápidamente fea y engorrosa cuando se hace algo más que una interfaz gráfica de usuario muy simple. He aquí una pequeña muestra de código de lo que estoy describiendo:

public class FooFrame extends JFrame { 

    JLabel inputLabel; 
    JTextField inputField; 
    JButton fooBtn; 
    JPanel fooPanel; 

    public FooFrame() { 
     super("Foo"); 

     fooPanel = new JPanel(); 
     fooPanel.setLayout(new FlowLayout()); 


     inputLabel = new JLabel("Input stuff"); 
     fooPanel.add(inputLabel); 

     inputField = new JTextField(20); 
     fooPanel.add(inputField); 

     fooBtn = new JButton("Do Foo"); 
     fooBtn.addActionListener(new ActionListener() { 
     public void actionPerformed(ActionEvent e) { 
      //handle event 
     } 
     }); 
     fooPanel.add(fooBtn); 

     add(fooPanel, BorderLayout.CENTER); 
    } 

} 

¿Es este tipo de uso del constructor de la mejor manera de codificar una aplicación Swing en Java? Si es así, ¿qué técnicas puedo usar para asegurarme de que este tipo de constructor esté organizado y pueda mantenerse? Si no, ¿cuál es la forma recomendada de abordar la preparación de un JFrame en Java?

Respuesta

1

Lamentablemente, hay muchos libros malos por ahí. Y un montón de código malo.

No se debe abusar de la herencia mediante su uso, donde no es necesario. (Está bien, no es el idioma doble Brace, que es el abuso de la herencia completa.) Esto se aplica a JFrame, JPanel, Thread y prácticamente todo, excepto java.lang.Object.

También es una muy buena idea hacer los campos private y donde sea posible final. Resulta que las referencias a los componentes generalmente no necesitan almacenarse en los campos, al menos no así.

+0

Así que estás diciendo que no extiendas innecesariamente JFrame como he hecho anteriormente, pero en una clase separada, ¿creas un nuevo JFrame y le agregas componentes? Este parece ser un curso de acción bastante razonable para lograrlo. ¿Conoces alguna buena referencia para consultar cómo estructurar el código de swing GUI? Gracias por el aporte. –

1

Como se acaba de decir, esto parece ser una técnica que se enseña en los libros. Lo que solía hacer, al menos tener un poco de una visión general sobre los diferentes aspectos, es separar las vistas de usuario de los controladores de usuario. En su caso, esto significaría que podría escribir clases separadas para Manejo de eventos. Otra técnica útil es usar métodos privados para separar diferentes partes de su UI. En otras palabras, las técnicas generales de Refactorización también pueden ser útiles en este caso.

3

Cuando se obtiene una interfaz de usuario más complejo que recomiendo que separe diferentes JPanels del JFrame, por lo que se convierte en "módulos" o "bloques de construcción" de la interfaz de usuario.

0

que no tienen reglas definidas aquí, excepto:

  • siempre hacen atributos privada, y cuando es posible final de
  • minimizar el uso de campos privados. Todos los componentes que no se utiliza fuera del constructor sólo debe ser declarada en el constructor y no como un campo (inputLabel en su ejemplo)
  • sólo utilizan los oyentes anónimos cuando hay poco código en cuestión. Cuando crecen demasiado grande, por lo general significa que tiene que separarlos o declarar en clases privadas o independientes
  • Y al igual que Jonas dijo a mantener el JFrame, JDialog etc. clases magras rompiendo los principales bloques de construcción en clases separadas.