Meilleure pratique avec les constructeurs JFrame?

Question

Dans mes deux classes Java, et les livres que nous avons utilisés dans leur disposition d'une interface graphique avec du code fortement impliqué le constructeur de la JFrame. La technique standard dans les livres semble être d'initialiser tous les composants et de les ajouter au JFrame dans le constructeur, et d'ajouter des gestionnaires d'événements anonymes pour gérer les événements si nécessaire, et c'est ce qui a été préconisé dans ma classe.

Cela semble être assez facile à comprendre, et facile à utiliser lors de la création d'une interface graphique très simple, mais semble devenir vite laide et encombrante en faisant autre chose qu'un gui très simple. Voici un petit exemple de code de ce que je décris:

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

} 

Est-ce type d'utilisation du constructeur la meilleure façon de coder une application Swing en Java? Si oui, quelles techniques puis-je utiliser pour m'assurer que ce type de constructeur est organisé et maintenable? Si non, quelle est la manière recommandée d'aborder l'assemblage d'un JFrame en java?

Answer 1

Malheureusement, il y a beaucoup de mauvais livres là-bas. Et beaucoup de mauvais code.

Vous ne devriez pas abuser de l'héritage en l'utilisant si cela n'est pas nécessaire. (D'accord, il est l'idiome Double Brace, qui est un abus complet d'héritage.) Cela vaut pour JFrame, JPanel, Thread et pratiquement tout sauf java.lang.Object.

Il est également une très bonne idée de faire des champs private et si possible final. Il s'avère que les références aux composants n'ont généralement pas besoin d'être stockées dans des champs, du moins pas comme ça.

Answer 2

Comme vous venez de le dire, cela semble être une technique enseignée par les livres. Ce que j'avais l'habitude de faire, pour au moins avoir un aperçu des différents aspects est de séparer les ui-vues des contrôleurs ui. Dans votre cas, cela signifierait que vous pourriez écrire des classes séparées pour le traitement des événements. Une autre technique utile consiste à utiliser des méthodes privées pour séparer différentes parties de votre interface utilisateur. En d'autres termes, les techniques générales de refactoring peuvent également être utiles dans ce cas.

Answer 3

Lorsque vous obtenez une interface plus complexe, je vous recommande de différents JPanels séparé du JFrame, de sorte qu'ils deviennent des « modules » ou « blocs de construction » de l'interface utilisateur.

Answer 4

Je n'ai pas de règles précises ici, à l'exception:

• toujours faire des attributs privés, et quand il est possible finale
• réduisent au minimum l'utilisation des champs privés. Chaque composant est pas hors du constructeur ne doit être déclaré dans le constructeur et non pas comme un champ (inputLabel dans votre exemple)
• utiliser uniquement les auditeurs anonymes quand il y a peu de code impliqué. Quand ils grandissent trop grand, cela signifie généralement que vous devez les briser ou les déclarer en privé, ou des classes séparées
• Et comme Jonas a dit garder le JFrame, JDialog etc. cours de vaches maigres en brisant les blocs principaux de construction dans des classes séparées.