¿Cuál es la forma común para programar los oyentes de acción?

Question

acabo de empezar a aprender a utilizar los oyentes de acción. A mi entender funciona de la siguiente manera:

1. Hay algunas clases que contiene método "addActionListener" por defecto (por ejemplo, clases para los botones).

2. El uso de este método que añadir un detector de acción a un objeto. Por ejemplo:. listenedObject.addActionListener(listeningObject)

3. Cuando se realiza una acción con el "listenedObject", el método "actionPerformed" de la "listeningObject" será llamado. Por lo tanto, esto significa que cuando programamos una clase para el listeningObject, tenemos que poner ahí método "actionPerformed".

Lo que no está claro para mí, ¿hay que crear una nueva clase para cada objeto que queremos escuchar. No parece a mí como una solución elegante. Por otro lado, si tenemos una clase de la acción de escucha para todos (al menos muchos o) objeto, que tenemos un problema ya que una instancia de esta clase no sabrá qué objeto está llamando el método "actionPerformed" (y necesitamos saber que desde acciones realizadas por el actionPerformed difiere dependiendo de quién está llamado a este método).

En mi opinión, para cada objeto escuchado tenemos que crear son oyente de action "personal" y lo podemos hacer mediante el establecimiento de un valor específico para el campo correspondiente del oyente acción. Pero no estoy seguro de que es una forma estándar para ir? ¿Cómo lo general la gente lo hace?

Answer 1

La forma más común de manejar esto - a juzgar por mi propia experiencia personal - es simplemente crear una clase en línea en el anonimato. De esta manera:

listenedObject.addActionListener(new ActionListener() {
    @Override
    public void actionPerformed(ActionEvent evt) {
        // Your action handling code in here
    }
});

Y la gente a menudo me he visto realizar una llamada a un método del objeto que contiene el listenedObject. Por ejemplo, en un diálogo que tiene un botón:

myOkayButton.addActionListener(new ActionListener() {
    @Override
    public void actionPerformed(ActionEvent evt) {
        okayButtonPressed();
    }
});

A continuación, más adelante en la clase de diálogo:

private void okayButtonPressed() {
    // Do what we need to do
}

Answer 2

Personnaly, cuando sea posible, prefiero utilizar un acción clase (como ejemplo una subclase de AbstractAction) en lugar de simplemente confiar en un oyente de action. De esta manera, me puede proporcionar la origina widget de un nombre, un icono, un texto de ayuda, y así sucesivamente ...

Answer 3

La forma siempre he encontrado útil (por navegación propósitos) es crear una clase interna anónima que entonces los delegados a la clase externa:

listenedObject.addActionListener(new ActionListener() {
    @Override
    public void actionPerformed(ActionEvent evt) {
        listenedObject_actionPerformed(evt);
    }
});


private void listenedObject_actionPerformed(ActionEvent evt) {
    //Your handling goes here
}

A continuación, es mucho más fácil para llegar a su código de manejo en un IDE usando una búsqueda estructural (CTRL + F12 en IDEA, CTRL + O en Eclipse).

El problema de usar una sola clase (como un MyCoolPanel GUI) como el oyente común a un grupo de sus componentes (botones, etc) es que el método actionPerformed continuación, tiene una gran cantidad de comparaciones if-else feos de averiguar el cual botón ha sido presionado en realidad - no es muy OO en absoluto

Por cierto, no debe ponerse demasiado preocupado por el rendimiento los aspectos de este tipo de cosas - que es probable que sea insignificante en el extremo! La optimización prematura es famoso una mala cosa

Answer 4

La forma en que siempre he encontrado útil es crear una clase separada que implementa la interfaz ActionListener y todos los otros métodos necesarios para llevar a la acción. De esta manera, una acción no está ligado a un objeto específico y puede ser disparado desde un botón, un menú, etc. Un poco como el patrón Comando supongo. Se mantiene el código simple.

clases anónimos no son reutilizables.

redirección al objeto que contiene el listenedObject conduce a clases gigantescas que son difíciles de mantener.

Answer 5

Tenga en cuenta que existe métodos removeActionListener por una razón. Puede omitir los oyentes limpiar si los objetos que escuchan morirá con el objeto que gestiona los eventos. Pero si su componente escucha el modelo suministrado desde una fuente externa, se debe añadir a sus oyentes en addNotify y eliminarlos en los métodos removeNotify. De lo contrario puede tener una fuga memore.

Answer 6

Tal vez no es en realidad en este momento, pero yo creo que en un futuro cercano (después de la liberación de Java 7) algo como esto sería la forma más común:

listenedObject.addActionListener ( #{doSmth();} );