2009-12-26 27 views
7

He hecho una aplicación Swing que es bastante simple en funcionalidad. Sin embargo, el código que lo compone se convirtió en bastante grande y muy desordenado en mi opinión. Todos los componentes y acciones de swing están en un archivo. Entonces, por ejemplo, si tuviera que hacer una aplicación aún más grande con más funcionalidad, el código será bastante difícil de procesar.pregunta general sobre Java Swing

Así que mi pregunta es cómo hacer una buena estructura del código. O si hay una buena página web que puedo leer al respecto, y si es posible algunos ejemplos de código. He consultado el tutorial de Sun sobre Swing, pero esos son ejemplos bastante simplistas que han mostrado.

ACTUALIZACIÓN: Tengo reflexionar un tiempo y buscar algunos ejemplos. No sé si obtuve el patrón MVC correcto. De todos modos, mi idea es separar cada JFrame de su propio archivo de clase. Después tengo un MainFrame que es la ventana principal para la aplicación. De ese JFrame creo una instancia de cada JFrame que tengo. Y llame a esos cuadros del MainFrame con Actions. No sé si esta es una buena idea. Sin embargo, hace que el código sea más fácil de leer de todos modos.

Aquí hay un ejemplo de cómo quería decir

class Main implements ActionListener { 

    private JFrame frame = new JFrame(); 
    private JButton button1 = new JButton(); 
    private JPanel panel = new JPanel(); 

    private FirstFrame frame1 = new FirstFrame(); 
    private SecondFrame frame2 = new SecondFrame(); 
    private ThirdFrame frame3 = new ThirdFrame(); 

    public Main() { 
     button1.addActionListener(this); 
    } 

    public createGUI() { 
     frame.setTitle("Main"); 
     frame.setSize(400,300); 
     panel.add(button); 

     frame.setVisible(true); 
     frame.setLocationRelativeTo(null); 
    } 

    public static void main(String args[]) { 
     new Main().createGUI(); 
    } 

    @Override 
    public void actionPerformed(ActionEvent e) { 
     if(e.getSource() == button1) 
     { 
      frame1.enable(); 
     } 
    } 
} 
+1

¡Gran pregunta! He estado reflexionando sobre esto por un tiempo. –

Respuesta

8

Uso Model-View-Controller design pattern. Se trata de la separación de código de la interfaz de usuario de la lógica de negocios.

EDIT:

Como OP está en busca de código organizado en lugar de un diseño flexible, he eliminado la parte Diseñador NetBeans interfaz de usuario de mi respuesta.

+0

He usado complementos de interfaz de usuario visual para Eclipse, pero mi experiencia es que agregará un montón de código de desecho. ¿Es este el mismo caso para Netbeans? – starcorn

+0

sin embargo, si hay recursos para leer también me gusta aprender a programar manualmente – starcorn

5

Organizar el código de la interfaz de usuario de cualquier tamaño significativo es un problema con sorprendentemente poco escrito al respecto, teniendo en cuenta que cada aplicación tiene el mismo problema. Hay algunas técnicas que pueden ayudar:

  1. Refactorización - para limpiar después de que el código se vuelva desordenado.
  2. Patrón de controlador de vista de modelo: para separar las preocupaciones.
  3. OO Design: utiliza muchas clases pequeñas que cooperan en lugar de grandes bloques de código.
  4. "En evento Do acción" - idioma para separar las acciones de las vistas.
  5. UML Modelos de componentes: visualice conceptos de diseño por encima del nivel de clase.
  6. Principio de inversión de dependencia: organizar dependencias de código.

Las técnicas básicas de diseño existen desde hace bastante tiempo, y se entienden bien, pero la aplicación de las técnicas a mayor escala es algo que parece diseñado individualmente para cada aplicación.

Un enfoque que he visto aplicado eficazmente es separar los eventos, los oyentes, las acciones, etc. en sus propias clases y organizarlos en paquetes por tipo, o utilizar una convención de nomenclatura coherente en los paquetes para que un componente sus clases asociadas son fácilmente identificables (XDialog, XDialogMouseListener, XDialogCancelAction, etc.).

Otro enfoque sería mirar algunas aplicaciones grandes de código abierto (Eclipse, Firefox, ...), y ver cómo organizan su código GUI.

+0

¿Cómo separe el código? Como tengo algunos puntos de vista Lo cual depende de las acciones, por lo tanto, no puedo separarlo. – starcorn

+0

Si divide una acción de una vista y ya no se compila, puede introducir métodos adicionales para permitir que las clases independientes accedan a la funcionalidad faltante. Los métodos adicionales deberían organizarse en interfaces. La interfaz se puede declarar con acceso a nivel de paquete si los métodos no deben estar disponibles públicamente. – richj

+0

En las vistas MVC normalmente no dependería de las acciones, aunque en MV2 la vista y el controlador se pueden acoplar más estrechamente. La introducción de interfaces le permite usar el Principio de Inversión de Dependencia para invertir la dirección de las dependencias que van por el camino equivocado. – richj

2

Tiendo a sacar tanta funcionalidad relacionada con la GUI de los componentes Swing como sea posible. Eso significa que tienes algo de indirección adicional. Sin embargo:

  1. la capa de oscilación no hace más que la interacción GUI
  2. la funcionalidad de negocio es mucho más fácil para poner a prueba y en consecuencia mantener

No estoy hablando necesariamente de un modelo completo MVC (aunque eso no es malo). Es más un problema de organización de clase/paquete.

+0

+1 por pragmatismo, hago lo mismo. Particularmente con un diseñador de GUI como JFormDesigner que hace que sea realmente fácil agregar acciones y manejadores de acciones para botones, etc. Tiene sentido tener todo eso en una sola clase, que llama clases de ayuda. Por ejemplo, mi acción de impresión es solo un contenedor que llama a la nueva PrintTask(). Print (myJob). PrintTask es una clase separada (no interna), que no tiene nada que ver con la GUI. –

1

Lo que hay que tener en mente es que la programación de IU es como otros tipos de programación. No piense que es especial y que puede ignorar prácticas sensatas. Desafortunadamente, la mayoría del código de tutorial es muy malo, y el código de producción tiende a ser mucho peor.

puntos clave:

  • utilizar un diseño en capas. Eso no es solo persistencia-business-ui. Dividirlo más fino. Por ejemplo, una capa de diseño no debe crear componentes (que no sean para el diseño, generalmente JPanel s).
  • Prefiere la composición a la herencia. Hay muy poco punto de subclases como JFrame y JPanel, así que no lo hagas.
  • Mantenga la IU delgada. Por ejemplo, los renderizadores deberían tener muy poca lógica en ellos. Por un lado, esto hace que las pruebas sean mucho más fáciles (es decir, las pruebas automatizadas, las pruebas a gran escala a mano son contraproducentes).