In Java, viene insegnato che le variabili devono essere mantenute private per consentire un migliore incapsulamento, ma per quanto riguarda le costanti statiche? Questo:"public static final" o "private static final" con getter?
public static final int FOO = 5;
sarebbe equivalente in seguito a questo:
private static final int FOO = 5;
...
public static getFoo() { return FOO; }
Ma che è meglio la pratica?
C'è un motivo per non utilizzare una costante direttamente nel codice.
supponga FOO potrebbe cambiare in seguito (ma ancora rimanere costante), dico public static final int FOO = 10;. Non dovrebbe rompere nulla fino a quando nessuno è abbastanza stupido da codificare il valore direttamente giusto?
No. Il compilatore Java inserirà costanti come Foo sopra nel codice chiamante, ovvero someFunc(FooClass.FOO); diventa someFunc(5);. Ora se ricompili la tua libreria ma non il codice chiamante puoi finire in situazioni sorprendenti. Ciò viene evitato se si utilizza una funzione: il JIT lo ottimizzerà ancora bene, quindi nessuna performance reale viene colpita.
Interessante, non l'ho mai capito, non mi sono mai imbattuto in costanti con getter in natura. –
Grazie per le informazioni, sembra che le costanti e i getter privati siano scelte empiricamente più sicure e dovrebbe essere considerata una pratica migliore –
@Chris Dipende da quali sono le tue costanti - ci sono molte costanti che sono impostate in pietra ('Pi' per esempio è abbastanza improbabile che diventi 3 dopo tutti questi anni;)) così io non condannerebbe l'uso di costanti pubbliche in tutti i casi, ma bisognerebbe tenerlo a mente, perché il debug di un tale problema è estremamente orribile – Voo
Da una variabile finale non può essere modificato in seguito, se hai intenzione di usarlo come una costante globale solo renderlo pubblico senza getter necessario.
Solo se sei assolutamente certo che non cambierai mai la variabile finale, le costanti sono delineate dal compilatore che possono portare a risultati estremamente sorprendenti se cambiano in seguito e non ricompilate tutto. – Voo
Getter è inutile qui e molto probabilmente sarà inline dalla JVM. Basta attenersi alla costante pubblica.
L'idea alla base è quello di proteggere l'incapsulamento modifiche indesiderate di una variabile e nascondere la rappresentazione interna. Con le costanti non ha molto senso.
Il primo se il risultato getFoo è costante e non ha bisogno di essere valutati in fase di esecuzione.
Il vantaggio di utilizzare setter e getter sull'organo è quello di essere in grado di sovrascrivere. Questo non è valido per "metodi" statici (piuttosto funzioni)
Non esiste anche alcun modo per definire i metodi statici delle interfacce.
vorrei andare con l'accesso campo
mi piacerebbe stare con la getFoo() in quanto consente di modificare l'implementazione in futuro senza modificare il codice del client. Come notato da @Tomasz, la JVM probabilmente incoronerà la tua attuale implementazione, quindi pagherai molto di una penalizzazione delle prestazioni.
Utilizzare le variales al di fuori della classe come:
public def FOO:Integer = 5;
Se l'incapsulamento non è la vostra priorità. Altrimenti usa la seconda variante in modo da esporre un metodo e non la variabile.
private static final int FOO = 5;
...
public static getFoo() { return FOO; }
È anche una pratica migliore per la manutenzione del codice non affidarsi a variabili. Ricorda che "l'ottimizzazione prematura è la radice di tutti i mali".
Voto per chiudere su non costruttivo (sulla base del feedback pareri già offerto). 'FOO' è davvero una costante? La classe fornisce la parte 'FOO' di un'API? O parte di un'applicazione endpoint? Ci sono costanti matematiche che non cambiano mai. Ci sono anche flag di bit che non dovrebbero mai cambiare (vedi SWT). Quindi la risposta è "Dipende." –