Best Practice with JFrame Constructors?

Question

In entrambe le mie classi Java, e i libri che usavamo in essi, la creazione di una GUI con codice coinvolgeva pesantemente il costruttore di JFrame. La tecnica standard nei libri sembra essere quella di inizializzare tutti i componenti e aggiungerli a JFrame nel costruttore, e aggiungere gestori di eventi anonimi per gestire gli eventi dove necessario, e questo è ciò che è stato sostenuto nella mia classe.

Questo sembra essere piuttosto facile da capire e facile da usare quando si crea una GUI molto semplice, ma sembra diventare rapidamente brutto e ingombrante quando si crea qualcosa di diverso da una semplice GUI. Ecco un esempio di codice piccolo di quello che sto descrivendo:

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

} 

E 'questo tipo di utilizzo del costruttore il modo migliore per codificare un'applicazione Oscillazione in java? In tal caso, quali tecniche posso utilizzare per assicurarmi che questo tipo di costruttore sia organizzato e manutenibile? In caso contrario, qual è il modo consigliato di avvicinarsi mettendo insieme un JFrame in java?

Answer 1

Purtroppo ci sono un sacco di libri cattivi là fuori. E un sacco di codice cattivo.

Non dovresti abusare dell'eredità usandola dove non è necessaria. (Va bene, c'è l'idioma Double Brace, che è completo abuso di ereditarietà.) Questo vale per JFrame, JPanel, Thread e praticamente tutto tranne java.lang.Object.

Inoltre è una buona idea creare campi private e ove possibile final. Risulta che i riferimenti ai componenti generalmente non hanno bisogno di essere immagazzinati nei campi, almeno non così.

Answer 2

Come hai appena detto, questa sembra essere una tecnica che viene insegnata dai libri. Quello che facevo, per avere almeno un po 'di panoramica sui diversi aspetti, è quello di separare le viste ui dagli ui-controller. Nel tuo caso ciò significherebbe che potresti scrivere classi separate per la gestione degli eventi. Un'altra tecnica utile consiste nell'utilizzare metodi privati ​​per separare parti diverse dell'interfaccia utente. In altre parole, le tecniche generali di Refactoring potrebbero essere utili anche in questo caso.

Answer 3

Quando si ottiene un'interfaccia utente più complessa, si consiglia di separare diversi JPanel da JFrame, in modo che diventino "moduli" o "blocchi" dell'interfaccia utente.

Answer 4

Non ho regole certe qui, tranne:

• sempre fare attributi privati, e quando è possibile finale
• minimizzare l'uso di campi privati. Ogni componente che non viene utilizzato al di fuori del costruttore deve essere dichiarato nel costruttore e non come un campo (inputLabel nel tuo esempio)
• utilizza solo listener anonimi quando è coinvolto un piccolo codice. Quando diventano troppo grandi, di solito significa che devi suddividerli o dichiararli in privato, o classi separate
• E come Jonas ha detto di mantenere le classi JFrame, JDialog, ecc. Rompendo gli elementi costitutivi principali in classi separate.