Java: ¿Los ActionListeners, KeyListeners, Etc, deben declararse siempre en clases internas?

Question

En todos los ejemplos de código fuente de Java que he observado, los oyentes siempre han sido declarados en clases internas.

¿Por qué? ¿Cuál es el motivo para codificar las clases como esta en lugar de tener el o los oyentes en su propio * archivo separado \ java?

¿Tener clases separadas para los oyentes se consideraría un mal diseño?

Si no es un mal diseño ofensa de saqueo, ¿podría alguien publicar un breve ejemplo que demuestre cómo implementar esto?

Gracias por leer.

Editar \ Actualizar - 10.8.2010: Gracias a todos los que se tomaron el tiempo para responder. Muchos puntos interesantes para considerar. Después de leer todas las respuestas, creo que a menos que haya una muy buena razón para hacerlo, es mejor y más fácil declarar a los oyentes como clases internas.

Disculpas por no volver a esta pregunta antes, pero no siempre tengo tanto tiempo para la codificación como me gustaría :-(

feliz de codificación.

Answer 1

buenas razones para usar clases internas:

• evita la adición de clases adicionales de nivel superior para el espacio de nombres paquete
• Mantiene el código encapsulado a nivel local (por ejemplo, dentro de la componente que requiere el comportamiento de manejo de eventos)
• clases internas estáticas funcionan bien cuando no es necesario para acceder a los campos de la clase envolvente

Posibles razones para usar las clases de nivel superior:

• Tiene un tipo de oyente especial que espera que use paquetes externos o que forme parte de su API (p.en la biblioteca de clases de Java en sí)
• El oyente se utiliza en muchos lugares, y no es lógicamente específica a cualquiera de las muchas posibles clases de cerramiento

En pocas palabras: las clases internas son generalmente preferidos, pero si usted tiene buenas razones, entonces puede ser perfectamente sensato crear clases de nivel superior.

Answer 2

Si usted ha visto en ejemplos es probable que parezca más fácil. La mayoría probablemente te diga que solo tomes tu clase actual e implementes el oyente. ¿Cuál parece más fácil ?: Creando 2 clases en 2 archivos, usando un oyente anidado dentro de una clase principal, o simplemente teniendo su clase principal como el oyente? (Sugerencia: No es el primero)

Soy flojo y solo tengo una clase principal para implementar el A interfaz ctionListener. Esto, por supuesto, solo funciona en GUI muy simples. Para proyectos más grandes, debes separarlos.

En cuanto a mantener al oyente en una clase separada, pregúntese: ¿otras clases necesitan usar esto? Las clases deben estar en su propio archivo SOLAMENTE si otros necesitan usarlas. Y compartir Listeners no es exactamente la mejor idea a menos que tengas un diseño extraño donde los botones hacen lo mismo pero están organizados de manera diferente para cada clase.

En resumen: mantenerlos anidados o implementados, no separados, a menos que sea necesario. Un caso necesario, sin embargo sería pocos y distantes entre

Answer 3

Sin duda podría tener el oyente implementado en un archivo de clase separado en un archivo .java por separado. Java 1.1 introdujo la clase anónima y la idea de clase interna junto con un nuevo diseño de evento hace años. La razón es que muchas veces los oyentes que escribe necesitan actualizar y/o leer los campos de la clase que contiene los objetos donde se generan los eventos. Es engorroso referirse a estos campos de una clase no interna/anónima.

Una vez que use más clases anónimas, verá que hace las cosas más simples de escribir y mantener más adelante. Los IDE modernos incluso generarán la mayor parte del código para usted de todos modos. Por ejemplo, escriba estas dos líneas en IntelliJ IDEA y presione ctrl-shift-space. IntellJ insertará una clase anónima que implmenta todos los métodos de la interfaz especificada por addActionListener().

JButton jb = new JButton("ok"); 
jb.addActionListener(new 

Answer 4

Una clase interna es local a la clase actual, que está muy bien en el caso de los que no tienen que ser utilizados en otros lugares. En un ejemplo en un libro, le da a la clase un nombre que permite consultarlo fácilmente desde la prosa.

El uso típico de los oyentes es que solo se utilizan en un solo lugar y para ese propósito las clases internas anónimas son perfectas. Para las interfaces con mucho método (como MouseListeners) generalmente hay un adaptador correspondiente con implementaciones vacías de todo lo que luego puede ser anulado según sea necesario. Ver MouseAdapter.

Answer 5

No, no creo que siempre deban ser clases internas. Implica que la IU siempre sabe cómo hacer la mejor elección de oyente.

Otra forma de verlo podría ser que los oyentes se inyectan en la interfaz de usuario. Tal vez los proporcione el controlador, que crea una instancia de la interfaz de usuario y le dice cómo reaccionar a los eventos de la interfaz de usuario.

Creo que esto es más una visión de inyección de dependencia del mundo. Puede haber ventajas importantes para esto.

Answer 6

This answer discute las compensaciones de las diferentes maneras.

La respuesta básica es que el código GUI en un programa suele estar bastante entrelazado y no suele compartirse entre programas. Hacer clases internas (especialmente si adoptas el modo que sugiero en la respuesta vinculada anterior) te permite estructurar el código de la GUI para que sea mantenible al tiempo que aceptas que la GUI está altamente acoplada.