Quando dovresti usare le Classi locali in Java?

Le classi locali sono solo un modo per incapsulare localmente alcuni stati e comportamenti.

Ma penso che tu abbia ragione; se vale la pena farlo, vale la pena farlo in un modo che è riutilizzabile, e ciò significa classi pubbliche, non locali. Le classi locali mi sembrano un po 'di odore di codice perché sono indicative di una definizione di classe esterna troppo ampia; cioè, è stato chiesto di fare troppo.

Posso pensare a un caso d'uso per le classi locali - creando una struttura per un oggetto che verrà restituito a un meccanismo che usa la riflessione per accedervi. Non so se qualcuno lo usa per questo scopo ...

Ad esempio, diciamo che hai un framework web AJAX. Il lato server ha un meccanismo di routing che indirizza una richiesta ai metodi Java, e quei metodi dovrebbero restituire oggetti che il meccanismo convertirà in qualche formato di serializzazione (XML / JSON / qualunque) e rimandarli al client.

Il client non ha bisogno della classe Java, perché esegue JavaScript e si preoccupa solo della struttura dei bean della classe. Il framework non ha bisogno di quella classe o non al momento della compilazione comunque. L'unico posto in cui verrà utilizzata la classe è il metodo che crea un oggetto e lo restituisce al sistema di routing del framework.

Ora, non puoi usare le classi anonime per questo perché non sarai in grado di popolare le loro proprietà (a meno che non usi un brutto attacco e crei un singolo metodo che imposta tutte le proprietà e restituisca this come Object ...), ma se si utilizza una classe locale può avere una funzione costruttore e setter che è possibile chiamare più di una volta.

Come hai detto tu, potresti anche usare definizioni di classi separate per questo, e so che il dogma ampiamente predicato dice che le dichiarazioni di classe dovrebbero essere collocate nel posto più visibile e accessibile possibile, ma rischio di essere bruciato puntare e affermare che non ogni singolo pezzo di codice deve essere ampiamente riusabile !

Ci sono degli svantaggi nel riutilizzo del codice. Uno di questi è che non è possibile modificare facilmente il codice riutilizzabile, perché non si sa dove altro viene utilizzato. Una gran parte degli schemi di progettazione che girano sono dedicati a risolvere questo svantaggio, ma a volte non vale la pena, ed è meglio limitare semplicemente il codice a essere utilizzabile in un singolo punto in modo da poterlo facilmente cambiare quando necessario.

Ad esempio, supponiamo che il metodo foo restituisca al nostro framework un oggetto Result con 3 campi - a , b e c . Un altro metodo, bar , ha anche bisogno di restituire quei 3 campi, e dato che non vuoi copiare 28 righe di codice ((1 riga per dichiarazione + 3 righe per setter + 3 linee per getter) * 3 campi + 2 linee per la classe + 5 linee per costruttore = 28 linee di codice. Java è quel maledetto verboso ...) usi Result in bar .

Ora, cosa succede se vuoi tornare da foo a un altro campo - d ? Non puoi semplicemente aggiungerlo a Result , perché bar usa anche Result e non puoi semplicemente restituire un d , perché bar non restituisce d , e lì potrebbero essere altri metodi che usano Result per altre cose. Quindi, applica il principio di apertura-chiusura e la sottoclasse Result in Result2 che aggiunge il campo d .

Ripeti 10 volte e ottieni una strana gerarchia di classi utilizzate esclusivamente per creare oggetti dati che saranno gestiti dalla riflessione ...

Non sarebbe meglio se ogni metodo avesse la propria classe locale Result che potresti modificare liberamente perché è locale e non c'è alcun rischio che altri metodi lo usino?