Best practice in relazione alle classi anonime nelle applicazioni UI

Question

Best practice in relazione alle classi anonime nelle applicazioni UI

#1 da (2 voti)
#2 da (1 voti)

8

Quando si lavora con programmi Java basati sull'interfaccia utente, un modo per attaccare il comportamento a determinate azioni (ad esempio per fare clic su un pulsante) è attraverso l'uso di classi anonime. Nell'esempio seguente, la struttura della GUI è SWT, tuttavia ho gli stessi problemi con i componenti dell'interfaccia utente di Swing o Android. Vale a dire la strutturazione dei miei programmi.

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();
    }
});

Naturalmente, alcuni potrebbero obiettare che la quantità di codice nell'esempio sopra già giustifica la creazione di una classe dedicata che contiene la logica. Questo è anche suggerito da di Sonar "Le classi anonime non dovrebbero avere troppe righe" regola.

È interessante notare che questa regola specifica anche che:

squid : S1188 - While waiting for support of closure in Java, anonymous classes is the most convenient way to inject a behavior without having to create a dedicated class. But those anonymous inner classes should be used only if the behavior can be accomplished in a few lines. With more complex code, a named class is called for.

Tuttavia, poiché le chiusure non sono ancora arrivate in Java, la mia domanda è se ci sono soluzioni più eleganti di :

scrivere un mucchio di codice all'interno di classi anonime che ha tutti i tipi di inconvenienti (riutilizzo limitato, navigazione più lenta attraverso il codice, ...)
creando un numero enorme di classi dedicate che a loro volta potrebbero avere funzionalità molto limitate (cioè: over-engineering, ...)

Per estendere la mia domanda: mi piacerebbe anche sapere quali sono le migliori pratiche in merito a questo aspetto delle applicazioni UI basate su Java? Ci sono dei modelli ben stabiliti?

java design-patterns ui

posta Jérôme 23.01.2014 - 22:41

fonte

2 risposte

Leggi altre domande sui tag java design-patterns ui

Funzioni opzionali: metodo predefinito o interfaccia separata globals statici e namespace anonimi in C ++

score 2 · Answer 1

L'unico pattern che ho visto, che funziona è "Quando il codice diventa difficile capire cosa sta succedendo, è ora di smettere di usare una classe anonima."

Nel tuo esempio, il corpo del metodo è la classe anonima. Potrei spostare il "nuovo SelectionAdapter" sulla propria linea, per rendere il paren di apertura un po 'più ovvio, ma per il resto va bene. Dove ti trovi nei guai è quando una persona a caso non può più capire dove sono la classe anonima e il codice del metodo.

Ho anche creato una variabile privata, o metodo per contenere la classe anonima. Ho messo quel genere di cose in fondo alla classe, fuori strada. È un po 'il modo di colmare il divario tra una nuova classe e tenerlo nel mezzo del codice. Alcuni lo considerano cattivo stile, ma la mia regola generale è quella di codificare prima la leggibilità.

score 1 · Answer 2

Le classi interiori anonime sono una cosa puramente stilistica; non esistono come tali all'interno della classe contenitore al livello del file .class che viene creato durante la compilazione; tutte le classi interne anonime DO creano un file .class separato come se fossero scritti come classi di primo livello.

Puoi vedere questo se passi alla directory di output (tipicamente chiamata "out") e cerca la classe interna per nome. Vedrai un file di classe separato per la tua classe interiore. Come ricordo il suo nome è OuterClassName $ InnerClassName.class. Il costruttore di una classe interna anonima (che viene creata anche se non lo scrivi tu stesso) riceve un riferimento a "questo" che ovviamente è la classe esterna contenente.

Quindi non basare la tua decisione su eventuali preoccupazioni che hai "facendo un sacco di classi". È puramente una cosa stilistica.

Quando ho avviato Java, le classi anonime mi sembravano un gran casino solo perché hanno violato il ritmo della classe che è andato come un metodo di metodo variabile variabile, quindi all'improvviso è apparso questo mucchio di codice. In realtà, mi irritano ancora leggermente.

Il loro presunto vantaggio è che rendono la comprensione del codice più facile - non devi andare in qualche altro file per vedere quale sarà il metodo della classe interna anonima. Ma è così.

Quindi la decisione è stilistica e nulla più. Se ti piace, usalo, se no, no.

volevo semplicemente aggiungere questo - potresti rivedere la tua idea che contenendo funzionalità limitate, ad esempio 1 metodo corto, all'interno di una classe dedicata costituisce un over-engineering. La classe, almeno in Java, è l'unità di coesione. La sovraingegneria non viene misurata in metodi per classe o conteggio di classe. O E è interamente ortogonale a entrambi.