2013-08-01 3 views
15

So come il compilatore interpreta la parola chiave finale in Java, ma come dovremmo noi programmatori interpretare il suo significato? Dovrebbe essere:interpretazione variabile finale

1) Questa variabile non può essere modificato (utilizzato da classe interna, per esempio)

o

2) Non ho intenzione di cambiare questa variabile (potrebbe avere un po 'di ottimizzazione benefici per le variabili membro).

Mi sto chiedendo perché ho lavorato sul codice dove tutto è dichiarata finale di default (sopra l'opzione 2), che, a mio parere, svaluta la parola chiave e nasconde i valori che davvero non può cambiare! Ci sono ancora benefici per le prestazioni nel dichiarare le variabili finali?

risposta

17

Tutto ciò che è definitivo per impostazione predefinita è un buona cosa. Più puoi modellare il tuo codice sull'immutabilità, più è facile a cui pensare.

L'utilizzo di final non è quasi mai uno spettacolo a mio parere. Si tratta di fare asserzioni sul resto del codice (nulla cambia questa variabile) che può aiutare un lettore a capire il codice e può essere controllato dal compilatore.

MODIFICA: Quanto sopra è la mia opinione per i campi. Per le variabili locali (compresi i parametri) io personalmente uso solo final quando la variabile verrà utilizzata in una classe interna anonima. Questo è diverso dai campi:

  • È facile vedere l'intero contesto del metodo e, in caso contrario, è un problema di per sé.
  • Poiché non rappresenta lo stato di un oggetto (o classe) i vantaggi dell'immutabilità non si applicano realmente.
+0

Accetto questo per le variabili membro, per quanto riguarda le variabili locali e parametri? Sicuramente c'è poco vantaggio nel contrassegnarli come finali, a meno che non debbano davvero essere? – StuPointerException

+0

C'è un vantaggio durante la lettura/mantenimento del codice. –

+0

L'unica lamentela che ho con 'final' è che ho bisogno di scriverlo del tutto. Ad esempio, emette le firme dei metodi, quindi non lo uso lì. Invece ho un avvertimento del compilatore di un parametro che cambia. –

1

La seconda opzione è una protezione. Ti impedisce di cambiare o riassegnare per errore. In quanto tale è utile fornire e puoi rimuoverlo quando decidi che vuoi cambiare quella variabile.

0

Non capisco perché pensi che ci sia mancanza di valore.

Quando vedo tutte le variabili finali, implica che la classe è immutabile. Questa è una buona cosa, perché le classi immutabili sono intrinsecamente thread-safe.

+0

Un elenco finale non è immutabile. –

+0

Il riferimento è certamente. Dovresti usare una collezione sincronizzata per modificarne il contenuto. – duffymo

0

le variabili finali sono a good thing in generale. Si noti che significa solo che la variabile non può essere riassegnata, ma l'oggetto che punta a può cambiare se è mutabile,.

Prestazioni saggio, final permette più aggressivo compiler optimisations:

la specifica consente di ottimizzare aggressiva dei campi finali. All'interno di un thread, è consentito riordinare le letture di un campo finale con quelle modifiche di un campo finale che non hanno luogo nel costruttore.

4

Ho scritto a post about this qualche tempo fa.

finale aiuta codice di lettura:

  • senza l'uso di tutto ciò finale può essere mutabile (potenziale disastro)
  • costringe impostare una variabile prima di poter essere utilizzato (utile nei costruttori)

Usando final si dice al compilatore qualcosa sul tuo codice e questo ti aiuta in cambio.

-1

È vero che la variabile finale viene utilizzata in modo che nessuno possa modificare il valore, funziona come costante in java.

Faccio esempio

ho creato un pacchetto che può essere utilizzato da qualche altra persona così, ora ci sono alcune variabili configurazioni che sono bisogno di impostare in modo da funzionare correttamente. diciamo il suo pacchetto di login. Quindi ci possono essere alcune opzioni di crittografia come

encryption_method = HASH_ENCRYPTION

O

encryption_method = SYMMETRIC_ENCRYPTION

invece di passare interi 1, 2, 3 possiamo definire variabile finale che aiuta gli sviluppatori in più forma leggibile e ofcource non voglio che l'utente lo cambi in modo da mantenerlo definitivo, altrimenti la logica interna potrebbe interrompersi

5

finale parola chiave dovrebbe essere abbandonata, dovrebbe essere standard in tutti i casi applicabili, e la finalità deve essere solo revocabile con parole chiave come

this_variable_will_change_unexpectedly_behind_your_back 

Questa parola chiave non dovrebbe avere compilato automaticamente da qualsiasi IDE, e non shoud essere possibile inseriscilo con Ctrl-V.

+3

Totalmente basato sull'opinione pubblica, ma mi capita di condividerne ogni parola :) –

+0

Mi piace, a parte la parte ctrl-V;) – StuPointerException

+3

E la battuta che "variabile" è venuta a significare "può cambiare alle tue spalle "... cosa direbbe il matematico se la sua variabile fosse cambiata in una singola espressione? –

1

Non posso aggiungere molto a ciò che Jon ha già detto, ma solo per completezza, JLS 17.5.3 dice che anche i campi finali possono portare a ottimizzazioni;

Se un campo finale viene inizializzato a una fase di compilazione espressione costante (§15.28) nella dichiarazione del campo, non possono essere osservate modifiche al campo finale, poiché usi di quel campo finale sono sostituiti in fase di compilazione con il valore dell'espressione costante.

0

Dichiarare tutte le variabili come final non sta svalutando final parola chiave. Aiuta gli sviluppatori a eseguire il debug dell'applicazione per escludere possibilità di modifica delle variabili, soprattutto durante l'ambiente di applicazione multi-thread.

con Java 8 rilascio, abbiamo un altro concetto chiamato "effectively final variable"

variabili

locali indicati da un'espressione lambda deve essere finale o efficacemente finale

A variabile è considerata finale effettivo se è non modificato dopo l'inizializzazione nel blocco locale. Ciò significa che ora puoi utilizzare la variabile locale senza parola chiave finale all'interno di un'espressione di classe anonima o lambda, a condizione che debbano essere effettivamente definitive.

Se non si desidera dichiarare la finale effettiva come variabile finale, questa nuova funzione è di aiuto se si utilizzano espressioni lambda/classi anonime. È possibile evitare la dichiarazione della parola chiave final per le variabili effective final. Date un'occhiata a questo article