Java/Android: clases locales anónimas vs clases nombradas

Question

Me gustaría preguntar cuál es la buena práctica sobre el uso de clases anónimas vs. clases internas con nombre?

Estoy escribiendo una aplicación de Android, que incluye muchos elementos de la interfaz de usuario (botones, campos de texto, etc.). Para muchos de ellos que necesitan algún tipo de oyentes, por lo que en onCreate de la aplicación tengo montón de muy pequeñas clases anónimas como:

someButton.setOnClickListener(
    new View.OnClickListener() { 
     public void onClick(View v) { 
      // do something... 
     } 
    } 
); 

Cada uno de dicha clase anónima es de 5 - 20 líneas grande - lo suficientemente pequeño y encaja bien para las recomendaciones de Java ™ en una cáscara de nuez libro:

en general, se debe considerar el uso de una clase anónima en lugar de una clase local si:

• La clase tiene un cuerpo muy corto.
• Solo se necesita una instancia de la clase.
• La clase se usa justo después de que se haya definido.
• El nombre de la clase no hace que su código sea más fácil de entender.

Pero el problema, la OMI, es que se convierte en onCreate bastante grande y el código se vuelve más compleja de leer y entender por rápida, de integrarse a ella. Todavía es fácil de entender, pero simplemente demasiado grande.

Entonces, ¿cuál sería la mejor práctica en tal caso? ¿Tiene un montón de pequeñas subclases internas, donde cada una de ellas está muy bien separada, pero se usa solo una vez o mejor, siga usando clases anónimas?

Answer 1

No creo que haya una respuesta clara en un sentido u otro. Ambos estilos funcionan bien, es realmente lo que prefieres.

Otra opción es tener

el contenido de cada onClick por una sola llamada de función, que mantendrá las clases anónimas muy corto. YO.e:

someButton.setOnClickListener(
    new View.OnClickListener() { 
     public void onClick(View v) { 
      doSomeButtonClick(); 
     } 
    } 
); 


private void doSomeButtonClick() { 
    // do something 
} 

Answer 2

Como sugiere la cita, esto es algo que es subjetivo. Necesita averiguar lo que cuenta como "muy corto" y "más fácil de entender" para usted, para determinar en qué punto el tamaño del código cruza la línea de algo que tiene sentido como clase anónima a algo que tiene sentido como propio unidad.

Cualquier respuesta que alguien le dé sobre esto se basa en sus propias medidas subjetivas de qué es "corto" y cuántas líneas de código se necesitan para no ser más "cortas".

Answer 3

Refactorice el onCreate() en métodos separados agrupados por la funcionalidad común para que tenga unidades lógicas. Si la GUI es compleja, te ayudará más adelante.

EDIT:

También, ya que son por defecto más sangrado por un formateador de código cuando dentro de una clase anónima sus líneas tienen que ser más corto para evitar que se rompa en varias líneas por el formateador por lo que es más largo. Esto suele ser lo que deja en claro que sería un buen momento para extraer la clase y darle un nombre.

Answer 4

No sé si es considerado por la comunidad como una buena práctica, pero cuando este tipo de clase se hace demasiado grande, creo un oyente paquete y crear mi clase en el mismo. ¿Por qué utilizar clase interna o clase anónima si se interpone en su camino más adelante en su código?

Pero la mayoría de las veces, si este tipo de clase se agranda, es porque usted no delegó lo suficiente. Tal vez otras clases deberían tener métodos que ayuden a tu oyente a ser más ligero.

Answer 5

Realizo aplicaciones de escritorio/Swing, pero creo que los conceptos son los mismos.

Prefiero manejar todos los eventos en una clase, así que creo una clase de Controlador e implemento todos los oyentes que necesito en esa clase. Luego, creo un método en el panel para cada tipo de oyente. Agrega al oyente a cada componente del panel que necesita escuchar. Paso el panel como primer argumento al constructor de la clase Controller y hago que invoque cada uno de esos métodos de adición de escucha en el panel. Luego instanciar el controlador cuando instalo el panel.

Esto me da varias ventajas:

• todo el código de manejo de eventos es en una clase.
• Cualquier cruce de funcionalidad entre eventos se capta y maneja fácilmente.
• Cualquier estado afectado se puede almacenar y controlar en una clase.
• Todos los códigos de manejo de eventos son independientes del código de diseño de componentes.
• La capa de Vista (Panel) no sabe nada sobre la capa de Controlador.

Dicho esto, si los eventos que está conectando hacen cosas simples, y estas cosas no entran en conflicto con otros eventos, entonces no es incorrecto utilizar clases anónimas.

Answer 6

Tiene varias ventajas al colocar estos elementos en clases con nombre.

El primero es el que usted menciona: hará que el método onCreate() sea más conciso y comprensible.

La segunda es que el nombre debe identificar rápidamente que la lógica va con qué botón, lo que hará que el código borra

La tercera es más fácil la separación de funciones. Si decide ir a un modelo de IoC, le resultará mucho más fácil inyectar las implementaciones nombradas de los oyentes.