ascoltatori di azione e sorgenti di eventi in Swing

Question

OK, quindi se posso aggiungere un ActionListener ad un elemento GUI, ed è il solo elemento che io uso ActionListener con, lo fa importa quale delle seguenti linee (a, b) che uso per ottenere la casella di controllo selezionato stato?

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

Ha senso per me che se aggiungo l'oggetto ActionListener a più elementi della GUI, quindi dovrei usare (b).

E nella (b), è OK per lanciare alla cieca event.getSource() a JCheckBox, dal momento che io sono quello che ha aggiunto l'action listener, o dovrei programmare in difesa e fare un controllo instanceof?

Nota: questa domanda è nel contesto di listener di eventi in generale; kdgregory ha alcuni buoni punti di seguito specificamente ri: caselle che avevo trascurato di prendere in considerazione

.

Answer 1

a (b) di essere rigorosi, si dovrebbe davvero fare un controllo instanceof, ma non è così importante. Penserei entrambe queste linee sono belle e accettabile, anche se (b) sarebbe "codice migliore"

Anche se, quello che di solito è fatto in un listener di azione è semplicemente chiamare un altro metodo di misura per la vostra casella. Quindi sarebbe simile a qualcosa di simile:

 @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

mi piacerebbe fare nessuno dei due.

Se facendo clic sulla casella di controllo sta per iniziare una certa azione, mi piacerebbe attaccare un ItemListener , poi basta guardare lo stato di selezione nel ItemEvent .

azioni Tuttavia, caselle di controllo normalmente non invocano, riescono Stato. Quindi, un approccio migliore è quello di esaminare tutte le caselle di controllo in risposta a ciò che non dare il via all'azione.

---

Modifica:. Qualche commento sui problemi più grandi che il PO ha sollevato

In primo luogo, è importante rendersi conto che gran parte di Swing rappresentano convenienza realizzazione, piuttosto che un modello di comportamento coerente. JCheckBox e JButton hanno nulla in comune tranne il fatto che cliccando all'interno del loro spazio è significativo. Tuttavia, entrambi ereditano da AbstractButton , che fornisce dettagli di implementazione come etichetta del pulsante. Si presuppone inoltre che i pulsanti sono "premuti", e che premendo un pulsante avvia un comportamento significativo (l'azione). Nel caso di JCheckBox, tuttavia, il pulsante non è importante, il cambiamento di stato è. Questo cambiamento di stato viene segnalato al ItemListener -. Che è anche definita sulla AbstractButton anche se i cambiamenti di stato sono privi di significato ad altri tipi di pulsanti (JavaDoc dice anche "checkbox")

Una delle cose che ha fatto arrivare subito swing - se difficile da usare - è l'idea di che un azione è separata dal controllo di avviare l'azione. Un oggetto d'azione può essere invocato da più controlli: una voce del menu, un pulsante su una finestra di dialogo, una combinazione di tasti, qualsiasi cosa. Più importante dal punto di vista di design è che ti porta lontano dall'idea di un "ascoltatore" generico che cerca di capire ciò che deve accadere. Ho visto le applicazioni in cui un singolo ascoltatore riceve input da tutto il sistema di menu, ad esempio, e poi attraversa un grande se la catena / altro per capire che la voce di menu è stato premuto. Utilizzando azioni significa avere più classi, ma a lungo andare ti dà un'applicazione più gestibile.

Infine, dal punto di vista dell'usabilità, c'è una differenza tra i controlli che mantengono lo stato, come JCheckBox e JTextArea, e quelli che avviare azioni, come JButton e JMenuItem. Ho visto un app (web), dove cliccando su un pulsante vi porta a una pagina diversa. Questo è male. Anche se si ha intenzione di utilizzare gli ascoltatori internamente, per aggiornare lo stato di alcuni modelli, si dovrebbe chiedere il motivo per cui la raccolta di elementi GUI per sé non vi fornirà un modello.

Answer 3

Per il caso in cui l'ascoltatore è esclusivo (come un ascoltatore anon), I (A).

Se l'ascoltatore sarà riutilizzato (per esempio, this è un'istanza di ActionListener) Io lo scrivo come:

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

Se si dispone di più caselle di controllo e sono trattati allo stesso modo, quindi instanceof ha un senso.

Answer 4

Mi piacerebbe programma con b difensiva in quanto è l'opzione migliore-pratiche. Ma se solo si sta mai intenzione di utilizzare il codice, allora non v'è alcun motivo per cui non si può fare a. Tuttavia, immaginare quanto felice sarai con te stesso se si torna ad esso in un momento futuro, cambiare qualcosa e trovare che hai scritto bene codice che è possibile riutilizzare direttamente ...