oyentes de acción y los orígenes de eventos de oscilación

Question

OK, así que si agrego una ActionListener a un elemento de interfaz gráfica de usuario, y es el solamente elemento de uso ese ActionListener con, qué importa cuál de las siguientes líneas (a, b) que uso para obtener el estado casilla seleccionada?

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

Tiene sentido para mí que si añado el objeto ActionListener a varios elementos de la GUI, entonces debería usar (b).

Y en (b), ¿está bien echado ciegamente event.getSource() a JCheckBox, ya que yo soy el que añadió el oyente de action, o debería programar la defensiva y hacer una comprobación instanceof?

Nota: esta pregunta es en el contexto de los detectores de eventos en general; kdgregory tiene algunos buenos puntos por debajo de re específicamente: casillas de verificación que había descuidado a considerar

.

Answer 1

en (b) sea rigurosa, que de hecho debe hacer una verificación instanceof, pero no es tan importante. Yo creo que estas dos líneas están bien y aceptable, aunque (b) sería "mejor código"

A pesar de que, por lo general lo que se hace en un oyente de action es simplemente llamar a otro método personalizado a su casilla de verificación. Así se vería algo como esto:

 @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

lo haría ninguno de ellos.

Si la casilla de verificación va a iniciar alguna acción, me conecto a una ItemListener , a continuación, basta con ver el estado de selección en el ItemEvent .

Sin embargo, casillas de verificación no suelen invocar acciones, se las arreglan estado. Por lo tanto un mejor enfoque consiste en examinar todas sus casillas de verificación en respuesta a todo aquello que dar comienzo a la acción.

---

Editar:. Algunos comentarios acerca de los problemas más grandes que el PO planteó

En primer lugar, es importante darse cuenta de que gran parte de oscilación representan conveniencia aplicación en lugar de un modelo de comportamiento coherente. JCheckBox y JButton no tienen nada en común, aparte del hecho de que al hacer clic dentro de su espacio es significativo. Sin embargo, ambos se heredan de AbstractButton , que proporciona detalles de implementación tales como la etiqueta del botón. También se supone que los botones están "presionados", y que al pulsar un botón iniciará un comportamiento significativo (la acción). En el caso de JCheckBox, sin embargo, el botón de prensa no es importante, el cambio de estado es. Ese cambio de estado se señaliza a la ItemListener -. Que también se definen en AbstractButton a pesar de los cambios de estado no tienen sentido para otros tipos de botones (el JavaDoc incluso dice "casilla de verificación")

Una de las cosas que hizo swing hacerlo bien - si es difícil de usar - es la idea de que un acción está separado del control de iniciación de la acción. Un objeto acción puede ser invocado desde múltiples controles: un elemento de menú, un botón en un cuadro de diálogo, una combinación de teclas, lo que sea. Más importante desde el punto de vista del diseño es que te aleja de la idea de un "oyente" genérico que trata de averiguar lo que debe suceder. He visto aplicaciones donde un solo oyente recibe la entrada de todo el sistema de menú, por ejemplo, y posteriormente ejecuta a través de un gran si la cadena / persona para averiguar qué elemento de menú se presionó. El uso de acciones significa que tiene más clases, pero a la larga le da una aplicación más fácil de mantener.

Por último, desde una perspectiva de usabilidad, hay una diferencia entre los controles que mantienen el estado, tales como JCheckBox y JTextArea, y aquellos que inician acciones, como JButton y JMenuItem. He visto una aplicación (web), donde al hacer clic en un botón de radio que lleva a una página diferente. Eso es malo. Incluso si usted está planeando utilizar los oyentes internamente, para actualizar el estado de algún modelo, usted debe preguntarse por qué el conjunto de elementos de la GUI en sí mismas no le proporcionará un modelo.

Answer 3

En el caso de que el oyente es exclusivo (tal como un oyente anon), uso (a).

Si se volverá a utilizar el oyente (por ejemplo, this es una instancia de ActionListener) Voy a escribir como:

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

Si usted tiene varias casillas de verificación y se procesan de la misma manera, entonces instanceof tiene sentido.

Answer 4

Me programa con b defensiva, ya que es la opción de mejores prácticas. Pero si sólo alguna vez se va a utilizar el código, entonces no hay razón por la cual no se puede hacer una. Sin embargo, imaginar lo feliz que estará con usted mismo si usted se vuelve a ella en algún momento futuro, cambiar algo y encontrar que escribió un buen código que se puede reutilizar directamente ...