Action -Hörer und Ereignisquellen in Swing

Question

Ok, wenn ich eine hinzufüge ActionListener zu einem GUI -Element, und es ist das nur Element Ich benutze das ActionListener Ist es wichtig, welche der folgenden Zeilen (a, b) ich das Kontrollkästchen ausgewählt habe?

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

Es macht für mich Sinn, dass, wenn ich das hinzufüge ActionListener Objekt mehrerer GUI -Elemente, dann sollte ich (b) verwenden.

Und in (b) ist es in Ordnung, blind zu werfen event.getSource() zu JCheckBox, da ich derjenige bin, der den Action -Hörer hinzugefügt hat, oder sollte ich defensiv programmieren und eine machen instanceof überprüfen?

Hinweis: Diese Frage steht im Zusammenhang mit Ereignishörern im Allgemeinen; Kdgregory hat einige gute Punkte unten, speziell Re -Kontrollkästchen, die ich versäumt hatte, um sie zu berücksichtigen.

Answer 1

In (b) sollten Sie tatsächlich eine Instanzprüfung durchführen, aber es ist nicht so wichtig. Ich würde denken, dass diese beiden Zeilen in Ordnung und akzeptabel sind, (b) wäre jedoch "besserer Code".

Was normalerweise in einem Aktionshörer getan wird, ruft einfach eine andere Methode auf, die an Ihr Kontrollkästchen angepasst wurde. So würde es so aussehen wie so:

 @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

Ich würde auch nicht tun.

Wenn Sie auf das Kontrollkästchen klicken, würde ich eine Aktion starten, ich würde anhängen ItemListener, Schauen Sie sich einfach den Auswahlzustand in der ItemEvent.

Kontrollkästchen rufen jedoch normalerweise keine Aktionen auf, sondern verwalten den Status. Ein besserer Ansatz besteht also darin, alle Ihre Kontrollkästchen als Antwort auf das zu untersuchen, was die Aktion startet.

---

Bearbeiten: Einige Kommentare zu den größeren Problemen, die das OP aufgeworfen hat.

Erstens ist es wichtig zu erkennen, dass große Teile von Swing die Implementierungskomfort und eher ein kohärentes Verhaltensmodell darstellen. JCheckbox und Jbutton Haben Sie nichts anderes als die Tatsache, dass es sinnvoll ist, in ihren Raum zu klicken. Sie erben jedoch beide von AbstractButton, die Implementierungsdetails wie das Etikett der Schaltfläche enthält. Es wird auch davon ausgegangen, dass die Schaltflächen "gedrückt" werden und dass das Drücken einer Taste ein aussagekräftiges Verhalten (die Aktion) initiiert. Bei JCheckbox ist die Taste jedoch nicht wichtig, die Änderung des Status ist jedoch. Diese Zustandsänderung wird dem ItemListener signalisiert, der auch auf AbstractButton definiert ist, obwohl Zustandsänderungen für andere Tastentypen bedeutungslos sind (das Javadoc heißt sogar "Kontrollkästchen").

Eines der Dinge, die schwingen, wurde richtig Aktion ist getrennt von der Kontrolle, die diese Aktion initiiert. Ein Aktionsobjekt kann aus mehreren Steuerelementen aufgerufen werden: ein Menüelement, ein Pushbutton auf einem Dialog, einen Tastenanschlag, was auch immer. Wichtiger aus der Designperspektive ist, dass Sie die Idee eines generischen "Hörers" wegnehmen, der versucht, herauszufinden, was passieren muss. Ich habe Apps gesehen, bei denen ein einzelner Hörer beispielsweise ein Eingang aus dem gesamten Menüsystem erhält und dann durch eine große If/sonst -Kette ausgeführt wird, um herauszufinden, welcher Menüelement gedrückt wurde. Wenn Sie Aktionen verwenden, haben Sie mehr Klassen, aber auf lange Sicht erhalten Sie eine wartbarere App.

Aus Sicht der Usability gibt es schließlich einen Unterschied zwischen den Kontrollen, die den Zustand wie JCheckbox und JtextArea aufrechterhalten, und denjenigen, die Aktionen wie Jbutton und JMenuitem initiieren. Ich habe eine (Web-) App gesehen, in der Sie auf ein Optionsfeld zu einer anderen Seite klicken. Das ist schlecht. Auch wenn Sie vorhaben, die Hörer intern zu verwenden, um den Zustand eines Modells zu aktualisieren, sollten Sie sich fragen, warum die Sammlung von GUI -Elementen Ihnen kein Modell bietet.

Answer 3

Für den Fall, in dem der Hörer exklusiv ist (z. B. ein Anon -Hörer), benutze ich (a).

Wenn der Zuhörer wiederverwendet wird (z. B., zB, this ist eine Instanz von ActionListener) Ich werde es schreiben als:

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

Wenn Sie mehrere Kontrollkästchen haben und sie auf die gleiche Weise verarbeitet werden, dann instanceof macht Sinn.

Answer 4

Ich würde mit B defensiv programmieren, da es die Best-Practice-Option ist. Aber wenn Sie nur den Code verwenden möchten, gibt es keinen Grund, warum Sie keine tun können. Stellen Sie sich jedoch vor, wie glücklich Sie mit sich selbst sein werden, wenn Sie zu einem künftigen Punkt darauf zurückkommen, etwas ändern und feststellen, dass Sie guten Code geschrieben haben, den Sie direkt wiederverwenden können ...