Meilleures pratiques de l'interface graphique Java/Swing (du point de vue du code) [fermé]


Contrairement à ce wiki, je cherche la bonne façon d'implémenter les contrôles GUI Swing du point de vue du codage.

Je suis en quête d'apprendre Java et ses outils GUI mais je trouve tutoriel Internet après tutoriel Internet qui jette tout dans main et je sais que ce n'est pas correct.

J'ai également essayé des systèmes RAD comme Netbeans et d'autres éditeurs "visuels" mais au moment où j'arrive au codage, j'ai un tas de code que je ne sais pas la moitié de ce qu'il fait, donc J'ai l'intention d'apprendre à balancer le code à la main, et je connais les contrôles de base et la mise en page, mais je veux le faire de la bonne façon.

Y a-t-il un modèle ou un standard qui me manque?

Exemples de questions...

Dois-je étendre JFrame et créer mon propre objet frame? (Je suppose que oui)

Est-ce que j'encapsule le menu principal à l'intérieur de cet objet frame? ou dois-je créer ses propres? etc...

Comment séparer la logique " Vue "de la logique" Application"?

Fondamentalement, je cherche quelle est la norme de l'industrie, sur la façon d'organiser le code GUI.

Author: Community, 2011-03-29

2 answers

Comme il semble y avoir un argument sur ce qui constitue les "meilleures pratiques", je vais vous donner ce que j'ai trouvé fonctionne le mieux pour moi, et mon raisonnement:

1. Chaque fenêtre doit s'étendre soit JFrame soit JDialog (selon le type de fenêtre). Cela permet de contrôler facilement les propriétés de la fenêtre sans spécifier un objet spécifique à chaque fois. C'est plus le cas général, cependant, car j'ai été connu pour le faire dans les deux sens.

2. La méthode main() doit être dans un classe distincte. Cela augmente la probabilité de pouvoir utiliser vos classes window ailleurs, car elles ne sont pas liées à des implémentations spécifiques. Techniquement, cela ne fait pas de différence, mais le code de démarrage de l'application n'appartient tout simplement pas à une fenêtre.

3. Les auditeurs doivent être dans des classes internes anonymes. Votre classe de niveau supérieur ne doit implémenter aucun écouteur. Cela empêche les hacks comme appeler les méthodes d'écoute de n'importe où sauf l'objet auquel ils sont joint.

Voici une application simple avec un seul cadre pour démontrer ces pratiques:

public class Main {
    public static void main(String[] args) {
        final String text = args[0];
        SwingUtilities.invokeLater(new Runnable() {
            @Override
            public void run() {
                final MyWindow wnd = new MyWindow(text);
                wnd.setVisible(true);
            }
        });
    }
}

public class MyWindow extends JFrame {
    public MyWindow(String text) {
        super("My Window");

        setDefaultCloseOperation(WindowConstants.DO_NOTHING_ON_CLOSE);
        addWindowListener(new WindowAdapter() {
            @Override
            public void windowClosing(WindowEvent e) {
                MyWindow.this.setVisible(false);
                MyWindow.this.dispose();
            }
        });

        final JButton btn = new JButton(text);
        btn.addActionListener(new ActionListener() {
            @Override
            public void actionPerformed(ActionEvent e) {
                JOptionPane.showMessageDialog(MyWindow.this, "Button Pressed", "Hey", JOptionPane.INFORMATION_MESSAGE);
            }
        });

        setLayout(new FlowLayout());
        add(btn);
        pack();
    }
}
 31
Author: Jonathan, 2013-04-13 03:54:47

Je suis d'accord avec tous les points de Jonathan.

  1. Chaque fenêtre doit étendre JFrame ou JDialog...

  2. La méthode main() doit être dans une classe à part...

  3. Les auditeurs doivent être dans des classes internes anonymes...

Je voudrais également ajouter ce qui suit:

4.) Utilisez GridBagLayout (GBL) judicieusement. GBL est un gestionnaire de mise en page très puissant, difficile à apprendre, mais très puissant.

5.) Envisagez de coder à la main toute votre interface utilisateur. Personnellement, je ne suis pas fan du code produit par les éditeurs visuels. Mais, cela dit, je n'ai pas utilisé d'éditeur visuel depuis plusieurs années. Ils pourraient être mieux à ce stade.

6.) Utilisez judicieusement JPanels. Regardez votre interface utilisateur et déterminez quels composants doivent se comporter de la même manière que les changements de taille d'écran, puis regroupez ces composants sur un JPanel. Envisagez d'utiliser JPanels à l'intérieur de JPanels pour obtenir votre bon comportement de redimensionnement.

J'adopte normalement une approche légèrement différente de celle de Jonathan pour que mes composants gèrent les événements, mais je crois que son approche est un peu plus propre que la mienne.

Aussi, étudiez vraiment l'utilisation de MVC et de l'architecture en couches. Il est vraiment préférable de ne pas mélanger l'interface utilisateur et la logique métier.

 10
Author: hooknc, 2017-05-23 12:26:01