Best Practice mit JFrame-Konstruktoren?

Question

In beiden meiner Java-Klassen, und die Bücher, die wir in ihnen verwendeten, die eine GUI mit Code auslegten, beteiligte stark den Konstruktor des JFrame. Die Standardtechnik in den Büchern scheint zu sein, alle Komponenten zu initialisieren und sie zu dem JFrame im Konstruktor hinzuzufügen, und anonyme Ereignisbehandlungsroutinen hinzuzufügen, um Ereignisse wo erforderlich zu behandeln, und das ist, was in meiner Klasse befürwortet wird.

Dies scheint ziemlich einfach zu verstehen und einfach zu arbeiten, wenn man eine sehr einfache GUI erstellt, aber scheint schnell hässlich und umständlich zu werden, wenn man etwas anderes als eine sehr einfache GUI macht. Hier ist ein kleines Codebeispiel von dem, was ich beschreibe:

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

} 

Ist diese Art der Verwendung des Konstrukteurs des beste Weg, um eine Swing-Anwendung in Java zu programmieren? Wenn ja, welche Techniken kann ich verwenden, um sicherzustellen, dass diese Art von Konstruktor organisiert und wartbar ist? Wenn nicht, was ist die empfohlene Vorgehensweise, um ein JFrame in Java zusammenzustellen?

Answer 1

Leider gibt es dort viele schlechte Bücher. Und viel schlechter Code.

Sie sollten die Vererbung nicht missbrauchen, indem Sie sie verwenden, wo es nicht notwendig ist. (Okay, es gibt das Double Brace-Idiom, das einen kompletten Vererbungsfehler darstellt.) Dies gilt für JFrame, JPanel, Thread und praktisch alles außer java.lang.Object.

Auch ist es eine sehr gute Idee, Felder private und wenn möglich final zu machen. Es stellt sich heraus, dass Verweise auf Komponenten in der Regel nicht in Feldern gespeichert werden müssen, zumindest nicht so.

Answer 2

Wie Sie gerade gesagt haben, scheint dies eine Technik zu sein, die von den Büchern gelehrt wird. Was ich getan habe, um zumindest einen Überblick über die verschiedenen Aspekte zu bekommen, ist die Trennung der ui-Ansichten von den ui-Controllern. In Ihrem Fall würde das bedeuten, dass Sie separate Klassen für die Ereignisbehandlung schreiben könnten. Eine weitere hilfreiche Methode besteht darin, private Methoden zu verwenden, um verschiedene Teile Ihrer Benutzeroberfläche zu trennen. Mit anderen Worten, die generellen Refactoring-Techniken könnten auch in diesem Fall hilfreich sein.

Answer 3

Wenn Sie eine komplexere Benutzeroberfläche erhalten, empfehle ich, dass Sie verschiedene JPanels vom JFrame trennen, so dass sie zu "Modulen" oder "Bausteinen" Ihrer Benutzeroberfläche werden.

Answer 4

Ich habe keine bestimmten Regeln hier, mit Ausnahme von:

• immer Attributen privat machen, und wenn es möglich ist endgültig
• die Verwendung von privaten Bereichen minimieren. Jede Komponente, die nicht außerhalb des Konstruktors verwendet wird, sollte nur im Konstruktor und nicht als Feld deklariert werden (in Ihrem Beispiel inputLabel)
• Verwenden Sie nur anonyme Listener, wenn wenig Code beteiligt ist. Wenn sie zu groß werden, bedeutet das normalerweise, dass man sie zerlegen oder in private Klassen oder separate Klassen einteilen muss.
• Und wie Jonas sagte, halte die Klassen JFrame, JDialog etc. schlank, indem du die Hauptbausteine ​​in separaten Klassen durchbrechst.