otra - funcion anonima java
¿El uso de clases anónimas en Java se considera malo o bueno? (14)
Sé que las clases anónimas guardan tipeo cuando se trata de implementar Listener y cosas similares. Intentan ser un reemplazo para algunos usos de cierres.
Pero, ¿qué piensa la comunidad sobre el valor de esta función de idioma? ¿Tiene sentido y lo usas regularmente? ¿Hace que el código sea más claro, más comprensible y más fácil de mantener? ¿O las clases anónimas hacen que el código sea menos legible?
¿Cuál es su opinión, y tenga ejemplos / argumentos útiles para respaldar su opinión?
Otro buen uso de la clase interna anónima es cuando necesita inicializar colecciones como ArrayList y Set. Esta práctica también se conoce como inicialización de doble llave Por ejemplo,
private static final Set<String> VALID_CODES = new HashSet<String>() {{
add("XZ13s");
add("AB21/X");
add("YYLEX");
add("AR2D");
}};
Obviamente, esto no se limita a las colecciones; se puede usar para inicializar cualquier tipo de objeto, por ejemplo, objetos Gui:
add(new JPanel() {{
setLayout(...);
setBorder(...);
add(new JLabel(...));
add(new JSpinner(...));
}});
Depende de lo que los compare. Preferiría tenerlos que no tenerlos, pero preferiría poder proporcionar bloques de código simple a métodos como Arrays.sort () que tener que crear explícitamente una clase que contenga mi implementación de compare ().
Estoy de acuerdo con lo que muchos otros han dicho en que son útiles para interfaces pequeñas cuando solo se usan una vez. Pero también agregaría la restricción de que si el código externo a la clase anónima debe ser alterado para que funcione, entonces no use una clase anónima.
Si tiene que comenzar declarando las variables como definitivas para acomodar la clase anon ya que las referencia, entonces use una clase interna. También he visto algunos malos olores de código donde las matrices finales (del tamaño 1) se utilizan para devolver resultados de clases anónimas.
Si limitar el alcance y el acceso tanto como sea posible es algo bueno, entonces las clases anónimas son muy buenas. Tienen un alcance limitado a la clase que los necesita. Cuando sea apropiado, diría que las clases anónimas son buenas.
En el instante en que duplique la misma función, se convierte en una mala idea. Reformúlelo en una clase pública que se defienda por sí misma. Los IDE con características de refacturación lo hacen fácil.
Tiene sentido usarlos, pero debe ser consciente de lo que se hace debajo. Solo los uso si necesito una clase para hacer algo muy específico que no necesito en ningún otro lado.
Utilizo clases anónimas principalmente para interfaces que tienen solo un método, es decir, Runnable o ActionListener . La mayoría de las interfaces más grandes protegen sus propias clases o implementación en una clase ya existente. Y como es mi opinión, no necesito argumentos para apoyarlo.
Utilizo principalmente las clases anónimas a) notación abreviada si la interfaz tiene uno o dos métodos y no afecta la legibilidad
b) situación en la que no podré justificar la creación de una clase nueva, por ejemplo, en swing, cuando tiene que adjuntar un actionlistner para permitir un JButton para una operación trivial.
Tiendo a usar clases internas anónimas en situaciones en las que no necesito tener una clase completa solo para realizar alguna tarea. Por ejemplo, si quiero implementar un ActionListener o Runnable , pero no creo que sea necesario tener una clase interna. Por ejemplo, para iniciar un Thread simple, usar una clase interna anónima podría ser más legible:
public void someMethod()
{
new Thread(new Runnable() {
public void run()
{
// do stuff
}
}).start();
}
En ciertos casos, como en el ejemplo anterior, puede aumentar la legibilidad, especialmente para tareas únicas, ya que el código que se va a ejecutar está escrito en un solo lugar. Usar una clase interna sería "deslocalizar" el código:
public void someMethod()
{
new Thread(new MyRunnable()).start();
}
// ... several methods down ... //
class MyRunnable implements Runnable
{
public void run()
{
// do stuff
}
}
Dicho esto, sin embargo, si va a haber casos en que se repita lo mismo, debería ser una clase separada, ya sea una clase regular o una clase interna.
Tiendo a usar clases internas anónimas en programas en los que solo estoy probando cosas en lugar de tenerlas como una característica central de una aplicación real.
Usamos las clases anónimas regularmente. Los encuentro fáciles de usar para implementar interfaces que tienen solo uno o dos métodos y donde la funcionalidad no se usa en ningún otro lado. Si usa la misma funcionalidad en otro lugar, debería haber una clase real para reutilizar.
Mi opinión es que las clases anónimas hacen que el código sea menos legible. Para la implementación de oyentes, las clases anónimas son útiles. Para desarrollar una aplicación GWT , las clases anónimas son la mejor opción. Para estos casos, si no estamos usando clases anónimas, la cantidad de líneas de código aumentará.
No hay nada intrínsecamente diferente o especial sobre las clases anónimas. En última instancia, son solo azúcar sintáctico con soporte para hacer referencia a la clase externa. Esto hace que sea más fácil crear adaptadores, al igual que la mayoría de las implementaciones de Iterator devueltas por el marco de Colecciones.
Si el uso de una clase anónima mejora o degrada la legibilidad es una cuestión de gusto. El problema principal definitivamente no está aquí.
Las clases anónimas, como las clases internas, llevan una referencia a la clase adjunta, lo que hace que las cosas no privadas que sin ella sean. Para ser breve, esta referencia de la clase que lo contiene puede escapar a través de la clase interna. Entonces, la respuesta es: es una muy mala práctica usar una clase interna si se publicó, ya que eso automáticamente publicaría la clase adjunta. por ejemplo:
changeManager.register(new ChangeListener() {
public void onChange(...) {
...
}});
Aquí, el ChangeLstener anónimo se pasa al método de registro de un ChangeManager . Al hacerlo, también se publicará automáticamente la clase adjunta.
Esta es definitivamente una mala práctica.
La clase anónima se ve principalmente en la aplicación GUI especialmente para el manejo de eventos. La clase anónima es útil en casos de implementación de interfaces pequeñas que contienen uno o dos métodos ... Por ejemplo ... usted tiene una clase en la que tiene dos o tres hilos y desea realice dos o tres tareas diferentes usando esos hilos. En esta situación, puede tomar la ayuda de una clase anónima para realizar las tareas que desee. mira el siguiente ejemplo
class AnonymousClass{
public static void main(String args[]){
Runnable run1=new Runnable(){
public void run(){
System.out.println("from run1");
}
};
Runnable run2=new Runnable(){
public void run(){
System.out.println("from run2");
}
};
Runnable run3=new Runnable(){
public void run(){
System.out.println("from run3");
}
};
Thread t1=new Thread(run1);
Thread t2=new Thread(run2);
Thread t3=new Thread(run3);
t1.run();t2.run();t3.run();
}
}
salida:
de run1
de run2
de run3
En el complemento de código anterior he usado tres hilos para realizar tres tareas diferentes. Mire, he creado tres clases anónimas que contienen la implementación del método de ejecución para realizar tres tareas pequeñas diferentes.
Las clases anónimas no "ocultan" el código, pero tienen TEND para que sea un poco menos reutilizable. Tenga en cuenta que esto se aplica a los cierres también.
De alguna manera, permiten algunos refactores agradables porque se te permite pasar código a un método. Esto se puede usar de manera muy efectiva para reducir la duplicación y ciertamente no estoy en contra de las clases / cierres anónimos, sin embargo, hay algunos casos en que pueden ser un inconveniente.
Primero, considere que el código de clase interno anónimo que está ingresando no se presta para reutilizarse en su código. Si está haciendo lo mismo en algún otro código, tendría que volver a escribirlo como algo más que una clase interna anónima para poder reutilizarlo, y en ese punto podría ser difícil saber que hay código en otro lugar para reutilizar.
Junto con la falta de reutilización es su dificultad para parametrizar, lo que lleva a mi mayor queja ... tienden a llevar a copiar y pegar código.
He visto bastantes GUI donde alguien comenzó con clases internas anónimas como respondedores al evento. Muchos tuvieron que hacer algo ligeramente diferente, por ejemplo, 5 líneas de código donde la única diferencia es una cadena en el medio. Una vez que tiene el hábito de usar clases internas, la solución más fácil es copiar y pegar el bloque y reemplazar esa cadena.
La solución de crear una nueva clase "Nombrada" que tiene un parámetro de cadena y pasar esa clase a todos los métodos rara vez se le ocurre a alguien en ese punto. Esta clase nombrada puede usar parámetros o herencia para definir diferentes comportamientos y códigos.
Soy fanático de los cierres y no odio las clases anónimas, solo señalo algunos escollos que he visto.