Las mejores prácticas con respecto a las clases anónimas en aplicaciones de IU

Cuando se trabaja con programas Java basados ​​en la interfaz de usuario, una forma de asociar el comportamiento a ciertas acciones (por ejemplo, al hacer clic en un botón) es mediante el uso de clases anónimas. En el ejemplo a continuación, el marco de la GUI es SWT, sin embargo, tengo los mismos problemas con los componentes Swing o Android UI. A saber, la estructuración de mis programas.

MenuItem sampleMenuItem = new MenuItem(popupMenu, SWT.NONE);
sampleMenuItem.addSelectionListener(new SelectionAdapter() {
    public void widgetSelected(SelectionEvent event) {
         doSomething();

         // handle all table entries
         for (int i=0; i<10; i++) {
             doSomething2();
         }

         doSomething3();
         doSomething4();
    }
});

Por supuesto, algunos podrían argumentar que la cantidad de código en el ejemplo anterior ya garantiza la creación de una clase dedicada que contenga la lógica. Esto también lo sugiere la regla "Las clases anónimas de Sonar no deberían tener demasiadas líneas" .

Curiosamente, esta regla también especifica que:

calamar: S1188 - Mientras se espera el soporte de cierre en Java, las clases anónimas son la forma más conveniente de inyectar un comportamiento sin tener que crear una clase dedicada. Pero esas clases internas anónimas deben usarse solo si el comportamiento se puede lograr en unas pocas líneas. Con un código más complejo, se requiere una clase con nombre.

Sin embargo, dado que los cierres aún no han llegado a Java, mi pregunta es si hay soluciones más elegantes que :

• escribir un montón de código dentro de clases anónimas que tiene todo tipo de inconvenientes (reutilización limitada, navegación más lenta a través del código, ...)
• creando una gran cantidad de clases dedicadas que todas ellas podrían tener una funcionalidad muy limitada (es decir: sobre ingeniería, ...)

Para ampliar mi pregunta: también me gustaría saber cuáles son las mejores prácticas con respecto a este aspecto de las aplicaciones de IU basadas en Java. ¿Hay algún patrón bien establecido?

El único patrón que he visto que funciona es "Cuando el código se vuelve difícil de entender qué está pasando, es hora de dejar de usar una clase anónima".

En su ejemplo, el cuerpo del método es la clase anónima. Podría mover el "nuevo Adaptador de selección" a su propia línea, para que el par de apertura sea un poco más obvio, pero por lo demás está bien. Donde te metes en problemas es cuando una persona aleatoria ya no puede descubrir dónde están la clase anónima y el código del método.

También he creado una variable privada o método para mantener la clase anónima. Puse ese tipo de cosas al final de la clase, fuera del camino. De alguna manera, cierra la brecha entre una clase completamente nueva y la mantiene en el medio del código. Sin embargo, algunas personas lo consideran mal estilo, pero mi regla general es codificar primero la legibilidad.

Las clases internas anónimas son algo puramente estilístico; no existen como tales dentro de la clase que contiene al nivel del archivo .class que se crea durante la compilación; todas las clases internas anónimas CREAN un archivo .class separado como si estuvieran escritas como clases de nivel superior.

Puede ver esto si navega hasta el directorio de salida (normalmente denominado "fuera") y busca la clase interna por su nombre. Verá un archivo de clase separado para su clase interna. Como recuerdo, su nombre es OuterClassName $ InnerClassName.class. Al constructor de una clase interna anónima (que se crea aunque no la escriba usted mismo) se le pasa una referencia a "esto", que por supuesto es la clase externa que lo contiene.

Así que no base su decisión en ninguna inquietud que tenga sobre "hacer muchas clases". Es puramente una cosa estilística.

Cuando comencé Java, las clases anónimas me parecían un gran desastre solo porque violaban el ritmo de la clase, que era algo así como un método de método variable variable, de repente apareció este montón de código. En realidad, todavía me irritan levemente.

Su supuesta ventaja es que facilitan la comprensión del código: no tiene que ir a otro archivo para ver qué hará el método de la clase interna anónima. Pero eso es todo.

Entonces la decisión es estilística y nada más. Si te gusta, úsalo, si no, no lo hagas.

solo quería agregar rápidamente esto: podría volver a considerar su idea de que contener una funcionalidad limitada, digamos 1 método breve, dentro de una clase dedicada constituye una ingeniería excesiva. La clase, al menos en Java, es la unidad de cohesión. El exceso de ingeniería no se mide en métodos por clase o incluso recuento de clases. OE es completamente ortogonal a ambos.