Utilizzo del modificatore "finale" ogniqualvolta applicabile in Java [chiuso]

In Java, c'è una pratica di dichiarare ogni variabile (locale o classe), parametro finale se lo sono davvero.

Sebbene ciò renda il codice molto più dettagliato, aiuta a leggere / afferrare facilmente il codice e previene anche gli errori poiché l'intenzione è chiaramente contrassegnata.

Cosa ne pensi e cosa segui?

Penso che tutto abbia a che fare con un buon stile di programmazione. Ovviamente puoi scrivere programmi validi e robusti senza usare molti finalmodificatori ovunque, ma quando ci pensi ...

Aggiungendo finala tutte le cose che non dovrebbero cambiare semplicemente si restringono le possibilità che tu (o il prossimo programmatore, lavorando sul tuo codice) interpreterai erroneamente o abuserai del processo di pensiero che ha portato al tuo codice. Almeno dovrebbe suonare alcune campane quando ora vogliono cambiare la tua cosa precedentemente immutabile.

All'inizio, sembra un po 'strano vedere molte finalparole chiave nel tuo codice, ma molto presto smetterai di notare la parola stessa e penserai semplicemente che quella cosa non cambierà mai da questo punto su (puoi prenderlo da me ;-)

Penso che sia una buona pratica. Non lo uso sempre, ma quando posso ed è logico etichettare qualcosa, finallo farò.

Ossessione per:

• Campi finali: contrassegnare i campi come finali li costringe a essere impostati entro la fine della costruzione, rendendo immutabile quel riferimento di campo. Ciò consente la pubblicazione sicura dei campi e può evitare la necessità di sincronizzazione su letture successive. (Si noti che per un riferimento ad oggetto, solo il riferimento al campo è immutabile - le cose a cui fa riferimento il riferimento all'oggetto possono ancora cambiare e ciò influisce sull'immutabilità.)
• Campi statici finali - Anche se ora uso enum per molti dei casi in cui utilizzavo campi finali statici.

Considera ma usa con giudizio:

• Classi finali - Il design del framework / API è l'unico caso in cui lo considero.
• Metodi finali - Fondamentalmente uguale alle classi finali. Se stai usando modelli di metodi come folli e segnando elementi finali, probabilmente stai facendo troppo affidamento sull'eredità e non abbastanza sulla delega.

Ignora se non ti senti anale:

• Parametri del metodo e variabili locali - RARAMENTE lo faccio principalmente perché sono pigro e trovo che ingombra il codice. Devo ammettere pienamente che la marcatura di parametri e variabili locali che non ho intenzione di modificare è "più giusta". Vorrei che fosse l'impostazione predefinita. Ma non lo è e trovo il codice più difficile da capire con le finali dappertutto. Se sono nel codice di qualcun altro, non li estrarrò, ma se scrivo un nuovo codice non li inserirò. Un'eccezione è il caso in cui devi contrassegnare qualcosa di definitivo in modo da poter accedere dall'interno di una classe interna anonima.

Devi davvero capire il pieno utilizzo della parola chiave finale prima di usarla. Può applicarsi e avere effetti diversi su variabili, campi, metodi e classi

Consiglierei di consultare l'articolo collegato di seguito per maggiori dettagli.

Parola finale sulla parola chiave finale

Il finalmodificatore, specialmente per le variabili, è un modo per far applicare al compilatore una convenzione generalmente sensata: assicurarsi che una variabile (locale o di istanza) sia assegnata esattamente una volta (non più né meno). Accertandosi che una variabile sia definitivamente assegnata prima di essere utilizzata, è possibile evitare casi comuni di a NullPointerException:

final FileInputStream in;
if(test)
  in = new FileInputStream("foo.txt");
else
  System.out.println("test failed");
in.read(); // Compiler error because variable 'in' might be unassigned

Impedendo che una variabile venga assegnata più di una volta, si scoraggia lo scoping overbroad. Invece di questo:

 String msg = null;
 for(int i = 0; i < 10; i++) {
     msg = "We are at position " + i;
     System.out.println(msg);
 }
 msg = null;

Si consiglia di utilizzare questo:

 for(int i = 0; i < 10; i++) {
     final String msg = "We are at position " + i;
     System.out.println(msg);
 }

Alcuni link:

• L'ultima storia (capitolo gratuito del libro "Hardcore Java")
• Alcuni schemi finali
• Assegnazione definitiva

Sono piuttosto dogmatico nel dichiarare ogni possibile variabile final. Ciò include i parametri del metodo, le variabili locali e, raramente, i campi oggetto valore. Ho tre ragioni principali per dichiarare le variabili finali ovunque:

1. Dichiarazione di intenzione: dichiarando una variabile finale, sto affermando che questa variabile deve essere scritta una sola volta. È un sottile suggerimento per gli altri sviluppatori e un grande suggerimento per il compilatore.
2. Applicazione di variabili monouso: credo nell'idea che ogni variabile debba avere un solo scopo nella vita. Dando a ciascuna variabile un solo scopo, riduci il tempo necessario per individuare lo scopo di quella particolare variabile durante il debug.
3. Consente l'ottimizzazione: so che il compilatore aveva trucchi per migliorare le prestazioni che si basavano specificamente sull'immutabilità di un riferimento variabile. Mi piace pensare che alcuni di questi vecchi trucchi prestazionali (o nuovi) saranno usati dal compilatore.

Tuttavia, penso che le classi e i metodi finali non siano altrettanto utili dei riferimenti alle variabili finali. La finalparola chiave, se utilizzata con queste dichiarazioni, fornisce semplicemente blocchi stradali ai test automatizzati e all'uso del codice in modi che non avresti mai potuto prevedere.

L'efficace Java ha un oggetto che dice "Favorisci oggetti immutabili". Dichiarare i campi come finali ti aiuta a fare alcuni piccoli passi verso questo, ma ovviamente c'è molto di più su oggetti veramente immutabili di così.

Se sai che gli oggetti sono immutabili, possono essere condivisi per la lettura tra molti thread / client senza problemi di sincronizzazione, ed è più facile ragionare su come viene eseguito il programma.

Non sono mai stato in una situazione in cui avere una parola chiave finale su una variabile mi ha impedito di fare un errore, quindi per il momento penso che sia una gigantesca perdita di tempo.

A meno che non ci sia una vera ragione per farlo (come nel caso in cui si desideri sottolineare un punto specifico sulla variabile finale) preferirei non farlo poiché trovo che il codice sia meno leggibile.

Se, tuttavia, non trovi che rende il codice più difficile da leggere o più lungo da scrivere, allora cerca di farlo.

Modifica: come chiarimento (e un tentativo di riconquistare voti negativi), non sto dicendo di non segnare le costanti come finali, sto dicendo di non fare cose come:

public String doSomething() {
  final String first = someReallyComplicatedExpressionToGetTheString();
  final String second = anotherReallyComplicatedExpressionToGetAnother();

  return first+second;
}

Rende solo il codice (secondo me) più difficile da leggere.

Vale anche la pena ricordare che tutto ciò che fa finale è impedirti di riassegnare una variabile, non la rende immutabile o qualcosa del genere.

Final dovrebbe essere sempre usato per le costanti. È anche utile per variabili di breve durata (all'interno di un singolo metodo) quando le regole per la definizione della variabile sono complicate.

Per esempio:

final int foo;
if (a)
    foo = 1;
else if (b)
    foo = 2;
else if (c)
    foo = 3;
if (d)        // Compile error:  forgot the 'else'
    foo = 4;
else
    foo = -1;

Sembra che uno dei più grandi argomenti contro l' uso della parola chiave finale sia che "non è necessario" e che "spreca spazio".

Se riconosciamo i numerosi vantaggi di "final", come sottolineato da molti grandi post qui, pur ammettendo che ci vuole più digitazione e spazio, direi che Java avrebbe dovuto rendere le variabili "final" per impostazione predefinita e richiedere che le cose fossero contrassegnate " mutable "se il programmatore vuole che sia.

Io uso final tutto il tempo per gli attributi degli oggetti.

La finalparola chiave ha una semantica di visibilità se utilizzata sugli attributi degli oggetti. Fondamentalmente, l'impostazione del valore di un attributo dell'oggetto finale avviene prima che il costruttore ritorni. Ciò significa che fintanto che non lasci che il thisriferimento sfugga al costruttore e lo usi finalper tutti attributi, il proprio oggetto è (in base alla semantica Java 5) garantito per essere correttamente costruito e, poiché è anche immutabile, può essere pubblicato in modo sicuro ad altri thread.

Gli oggetti immutabili non riguardano solo la sicurezza dei thread. Inoltre rendono molto più facile ragionare sulle transizioni di stato nel tuo programma, perché lo spazio di ciò che può cambiare è deliberatamente e, se usato coerentemente, completamente limitato alle sole cose che dovrebbero cambiare.

A volte anche i metodi sono definitivi, ma non così spesso. Raramente faccio lezioni definitive. In genere lo faccio perché ne ho poco bisogno. In genere non uso molto l'eredità. Preferisco invece utilizzare interfacce e composizione di oggetti: questo si presta anche a un design che trovo spesso più facile da testare. Quando si codifica su interfacce anziché su classi concrete, non è necessario utilizzare l'ereditarietà quando si esegue il test, così com'è, con framework come jMock, molto più facili da creare oggetti simulati con interfacce rispetto alle classi concrete.

Immagino che dovrei rendere definitiva la maggior parte delle mie lezioni, ma non sono ancora entrato nell'habbit.

Devo leggere molto codice per il mio lavoro. La mancanza di variabili di istanza finali è una delle cose principali che mi infastidiscono e rende la comprensione del codice inutilmente difficile. Per i miei soldi, il finale sulle variabili locali causa più disordine che chiarezza. La lingua avrebbe dovuto essere progettata per renderla predefinita, ma dobbiamo convivere con l'errore. A volte è utile in particolare con loop e assegnazione definita con un albero if-else, ma tende principalmente a indicare che il tuo metodo è troppo complicato.

final dovrebbe ovviamente essere usato sulle costanti e per imporre l'immutabilità, ma c'è un altro uso importante sui metodi.

L'efficace Java ha un intero oggetto su questo (elemento 15) sottolineando le insidie ​​dell'eredità involontaria. In effetti, se non hai progettato e documentato la tua classe per ereditarietà, ereditare da essa può dare problemi imprevisti (l'elemento fornisce un buon esempio). Pertanto, si consiglia di utilizzare final su qualsiasi classe e / o metodo da cui non si intende ereditare.

Può sembrare draconiano, ma ha senso. Se stai scrivendo una libreria di classi per l'utilizzo da parte di altri, non vorrai che ereditino da cose che non sono state progettate per esso - ti bloccherai in una particolare implementazione della classe per la retrocompatibilità. Se stai programmando una squadra, non c'è nulla che impedisca a un altro membro della squadra di rimuovere la finale, se è davvero necessario. Ma la parola chiave li induce a pensare a quello che stanno facendo e li avverte che la classe da cui stanno ereditando non è stata progettata per questo, quindi dovrebbero stare molto attenti.

Un altro avvertimento è che molte persone confondono final per indicare che il contenuto della variabile di istanza non può cambiare, piuttosto che il riferimento non può cambiare.

Anche per le variabili locali, sapere che è dichiarato final significa che non devo preoccuparmi che il riferimento venga modificato in seguito. Ciò significa che quando eseguo il debug e vedo quella variabile in seguito, sono sicuro che si riferisca allo stesso oggetto. Questa è un'altra cosa di cui devo preoccuparmi quando cerco un bug. Un vantaggio è che se il 99% delle variabili viene dichiarato definitivo, le poche variabili realmente variabili si distinguono meglio. Inoltre, la finale consente al compilatore di trovare altri possibili stupidi errori che altrimenti potrebbero passare inosservati.

La scelta di digitare finalper ciascun parametro in ciascun metodo produrrà così tanta irritazione sia per i programmatori che per i lettori di codici.

Una volta che l'irritazione va oltre il ragionevole passaggio a Scala, dove gli argomenti sono finali per impostazione predefinita.

In alternativa, puoi sempre utilizzare strumenti di styling del codice che lo faranno automaticamente per te. Tutti gli IDE li hanno implementati o come plugin.

Final quando usato con variabili in Java fornisce un sostituto per costante in C ++. Quindi quando si usa final e static per una variabile diventa immutabile. Allo stesso tempo, rende abbastanza felici i programmatori C ++ migrati ;-)

Se utilizzato con variabili di riferimento, non consente di fare nuovamente riferimento all'oggetto, sebbene l'oggetto possa essere manipolato.

Quando final viene utilizzato con un metodo, non consente al metodo di essere superato dalle sottoclassi.

Una volta che l'uso è molto chiaro, dovrebbe essere usato con cura. Dipende principalmente dal design in quanto l'uso del metodo finale non aiuta il polimorfismo.

Si dovrebbe usarlo solo per le variabili quando si è dannatamente sicuri che il valore della variabile non sarà / non dovrà mai essere modificato. Assicurati inoltre di seguire la convenzione di codifica incoraggiata da SUN.per ad esempio: final int COLOR_RED = 1; (Maiuscolo separato da trattino basso)

Con una variabile di riferimento, usala solo quando abbiamo bisogno di un riferimento immutabile a un particolare oggetto.

Per quanto riguarda la parte di leggibilità, ne consegue che i commenti svolgono un ruolo molto importante quando si utilizza il modificatore finale.

Non li uso mai su variabili locali, c'è poco senso per la verbosità aggiunta. Anche se non pensi che la variabile debba essere riassegnata, ciò farà poca differenza alla persona successiva che modifica quel codice che la pensa diversamente, e poiché il codice viene modificato, qualsiasi scopo originale per renderlo definitivo potrebbe non essere più valido. Se è solo per chiarezza, credo che fallisca a causa degli effetti negativi della verbosità.

Praticamente lo stesso vale anche per le variabili membro, in quanto forniscono pochi vantaggi, tranne nel caso delle costanti.

Inoltre non ha alcuna influenza sull'immutabilità, poiché il miglior indicatore di qualcosa di immutabile è che è documentato come tale e / o non ha metodi che possono alterare l'oggetto (questo, insieme a rendere la classe finale è l'unico modo per garantire che è immutabile).

Ma hey, questa è solo la mia opinione :-)

Ho impostato Eclipse per aggiungere il finale su tutti i campi e gli attributi che non sono stati modificati. Funziona alla grande usando Eclipse "salva azioni" che aggiunge questi modificatori finali (tra le altre cose) quando si salva il file.

Altamente raccomandato.

Dai un'occhiata al mio post sul blog di Eclipse Save Actions.

Per argomenti, penso che non siano necessari. Mostley hanno solo ferito la leggibilità. Riassegnare una variabile argomento è così follemente stupido che dovrei essere abbastanza fiducioso che possano comunque essere trattati come costanti.

Il fatto che Eclipse colora il rosso finale semplifica l'individuazione delle dichiarazioni variabili nel codice che, a mio avviso, migliora la leggibilità per la maggior parte del tempo.

Cerco di imporre la regola secondo cui tutte le variabili dovrebbero essere definitive se non esiste un motivo estremamente valido per non farlo. È molto più facile rispondere a "cos'è questa variabile?" domanda se devi solo trovare l'inizializzazione ed essere sicuro che sia così.

In realtà sono un po 'nervoso per le variabili non definitive ora un giorno. È come la differenza tra avere un coltello appeso a un filo sulla testa o semplicemente averlo nel cassetto della cucina ...

Un'ultima variabile è solo un bel modo per etichettare i valori.

Una variabile non finale è legata a parte di un algoritmo soggetto a bug.

Una caratteristica interessante è che quando l'opzione di utilizzare una variabile fuori questione per un algoritmo per la maggior parte del tempo, la sollution è quella di scrivere un metodo, che di solito migliora significativamente il codice.

Sto programmando da un po 'di tempo e usando final ogni volta che posso. Dopo averlo fatto per un po '(per variabili, parametri di metodo e attributi di classe), posso dire che il 90% (o più) delle mie variabili sono effettivamente definitive. Penso che il vantaggio di NON avere le variabili modificate quando non si desidera (l'ho visto prima ed è un dolore a volte) paga per la digitazione aggiuntiva e le parole chiave "finali" extra nel codice.

Detto questo, se volessi progettare una lingua, renderei ogni variabile finale se non modificata da qualche altra parola chiave.

Non uso molto il finale per classi e metodi, pensavo. Questa è una scelta di progettazione più o meno complicata, a meno che la tua classe non sia una classe di utilità (nel qual caso dovresti avere un solo costruttore privato).

Uso anche Collections.unmodifiable ... per creare elenchi non modificabili quando ne ho bisogno.

L'uso di classi locali anonime per i listener di eventi e tale è un modello comune in Java. L'uso più comune della parola chiave finale è assicurarsi che le variabili nell'ambito siano accessibili al listener pari.

Tuttavia, se ti viene richiesto di inserire molte dichiarazioni finali nel tuo codice. Potrebbe essere un buon suggerimento che stai facendo qualcosa di sbagliato.

L'articolo pubblicato sopra fornisce questo esempio:

public void doSomething(int i, int j) {
    final int n = i + j; // must be declared final

    Comparator comp = new Comparator() {
        public int compare(Object left, Object right) {
            return n; // return copy of a local variable
        }
    };
}

Lo uso per le costanti all'interno e all'esterno.

Lo uso solo a volte per i metodi perché non so se una sottoclasse NON vorrebbe sovrascrivere un determinato metodo (per qualsiasi motivo).

Per quanto riguarda le classi, solo per alcune classi di infrastruttura, ho usato la classe finale.

IntelliJ IDEA avvisa se un parametro di funzione viene scritto all'interno di una funzione. Quindi, ho smesso di usare final per gli argomenti delle funzioni. Non li vedo nemmeno nella libreria Java Runtime.

Difficilmente uso il metodo finale o i metodi perché mi piace consentire alle persone di ignorarli.

Altrimenti, lo uso finalmente solo se è un public/private static final type SOME_CONSTANT;

Contrassegnare la classe finale può anche far accadere alcuni vincoli di metodo in fase di compilazione anziché in fase di esecuzione. Considera "v2.foo ()" di seguito: il compilatore sa che B non può avere una sottoclasse, quindi foo () non può essere sovrascritto, quindi l'implementazione da chiamare è nota al momento della compilazione. Se la classe B NON è contrassegnata come definitiva, è possibile che il tipo effettivo di v2 sia una classe che estende B e ignora foo ().

class A {
    void foo() {
        //do something
    }
}
final class B extends A {
    void foo() {
    }
}
class Test {
    public void t(A v1, B v2) {
        v1.foo();
        v2.foo();
    }
}

L'uso di final per le costanti è fortemente incoraggiato. Tuttavia, non lo userei per metodi o classi (o almeno ci penserei per un po '), perché rende i test più difficili, se non impossibili. Se devi assolutamente rendere definitiva una classe o un metodo, assicurati che questa classe implementi un'interfaccia, in modo da poter avere una simulazione dell'implementazione della stessa interfaccia.