les auditeurs d'action et les sources d'événements Swing

Question

OK, donc si j'ajouter un ActionListener à un élément graphique, et il est le uniquement élément j'utilise ce ActionListener avec, est-il important que des lignes suivantes (a, b) que j'utilise pour obtenir la case à cocher état sélectionné?

final JCheckBox checkbox = (JCheckBox)this.buildResult.get("cbDebugTick");
checkbox.addActionListener(new ActionListener() {
    @Override public void actionPerformed(ActionEvent event){               
            boolean bChecked =
            // (a) checkbox.isSelected();
            // (b) ((JCheckBox)event.getSource()).isSelected();
            model.setPrintDebugOn(bChecked);
        }
});

Il me semble logique que si j'ajoute l'objet ActionListener à plusieurs éléments de l'interface graphique, alors je devrais utiliser (b).

Et (b), est-il correct de event.getSource() aveuglément jeté à JCheckBox, depuis que je suis celui qui a ajouté l'auditeur d'action, ou devrais-je défensivement programme et faire une vérification de instanceof?

Note: cette question dans le contexte des auditeurs d'événements en général; kdgregory a quelques bons points ci-dessous spécifiquement re: que j'avais checkboxes négligé de considérer

.

Answer 1

(b) d'être rigoureux, vous devez en effet faire une vérification instanceof, mais il est pas si important. Je pense que ces deux lignes sont très bien et acceptable, bien que (b) serait « meilleur code »

Bien que, ce qui se fait habituellement dans un écouteur d'action est une autre méthode simplement appel personnalisée à votre case à cocher. Donc, il ressemblerait à quelque chose comme ceci:

 @Override public void actionPerformed(ActionEvent event) {                                  
    //your treatment would be in this method, where it would be acceptable to use (a)                  
    onCheckBoxActionPerformed(event)
}

Answer 2

Je ferais ni.

Si cochant la case va commencer une action, je joins un ItemListener , puis il suffit de regarder l'état de sélection dans la section ItemEvent .

Cependant, les cases à cocher n'invoquent pas normalement les actions, ils gèrent l'État. Ainsi, une meilleure approche est d'examiner toutes vos cases en réponse à tout ce qui ne coup d'envoi de l'action.

---

Modifier. Quelques commentaires au sujet des grandes questions que l'OP soulevées

Tout d'abord, il est important de se rendre compte que de grandes parties Swing représentent la commodité de mise en œuvre plutôt qu'un modèle de comportement cohérent. JCheckBox et AbstractButton , qui fournit des détails de mise en œuvre tels que l'étiquette du bouton. Il suppose également que les boutons sont « pressés », et en appuyant sur un bouton déclenche un comportement significatif (l'action). Dans le cas de JCheckBox, cependant, la presse bouton est pas important, le changement d'état est. Ce changement d'état est signalé à l'ItemListener -. Qui est également défini sur AbstractButton même si les changements d'état sont vides de sens à d'autres types de boutons (la JavaDoc dit même « case »)

L'une des choses que swing a réussi à avoir droit - si difficile à utiliser - est l'idée de cette une d'action est distinct du contrôle initiant cette action. peut être invoqué un objet d'action de multiples contrôles: un élément de menu, un bouton-poussoir sur une boîte de dialogue, une combinaison de touches, peu importe. Plus important du point de vue de la conception est qu'il vous éloigne de l'idée d'un « auditeur » générique qui essaie de comprendre ce qui doit arriver. J'ai vu des applications où un seul auditeur reçoit l'entrée du système de menu complet, par exemple, puis passe par un gros si / chaîne d'autre pour savoir quel élément de menu a été pressé. Utilisation d'actions signifie que vous avez plus de classes, mais à long terme, vous donne une application plus maintenable.

Enfin, du point de vue de la facilité d'utilisation, il y a une différence entre les contrôles qui maintiennent l'état, comme JCheckBox et JTextArea, et ceux qui initient des actions telles que JButton et JMenuItem. Je l'ai vu une application (Web) où en cliquant sur un bouton radio vous amène à une autre page. C'est mauvais. Même si vous avez l'intention d'utiliser les auditeurs internes, de mettre à jour l'état d'un certain modèle, vous devriez vous demander pourquoi la collection d'éléments de l'interface graphique ne le font pas en eux-mêmes vous fournir un modèle.

Answer 3

Pour le cas où l'auditeur est exclusif (comme un écouteur d'Anon), je l'utilise (a).

Si l'auditeur sera réutilisée (par exemple, this est une instance de ActionListener) Je vais écrire comme:

@Override
public void actionPerformed(ActionEvent event) {
    Object src = event.getSource();
    if (src == checkbox) {
        boolean bChecked = checkbox.isSelected();
        // ...
    }
}

Si vous avez plusieurs cases à cocher et ils sont traités de la même façon, alors instanceof est logique.

Answer 4

Je programme avec b défensivement car il est l'option la plus pratique. Mais si seulement vous allez jamais utiliser le code alors il n'y a aucune raison pour laquelle vous ne pouvez pas faire. Cependant, imaginer à quel point vous serez heureux avec vous-même si vous revenez à elle à un moment donné, changer quelque chose et vous trouverez un bon code écrit que vous pouvez réutiliser directement ...