Perché la parola chiave "finale" è utilizzata così poco nel settore? [chiuso]

Sospetto che il motivo per cui non lo vedi è perché il JDK è progettato per essere esteso (è la base da cui tutti i tuoi programmi sono costruiti). Non sarebbe affatto raro che il codice applicativo ne facesse uso. Inoltre, non mi aspetto di vederne molto nel codice libreria (dato che le librerie sono spesso progettate anche per l'estensione).

Prova a dare un'occhiata ad alcuni buoni progetti open source e penso che troverai di più.

Contrariamente a ciò che stai vedendo in Java, nel mondo .NET, ho sentito l'argomento molte volte che clases dovrebbe essere sealed (simile alla finale applicata ad una classe) per default, e che il lo sviluppatore dovrebbe annullarlo esplicitamente.

Il problema con l'utilizzo di final per comunicare che qualcosa è di sola lettura è che funziona solo per tipi primitivi come int , char ecc. Tutti gli oggetti in Java sono effettivamente riferiti usando un (tipo di puntatore. Di conseguenza, quando si utilizza la parola chiave final su un oggetto, si sta solo dicendo che il riferimento è di sola lettura, l'oggetto stesso è ancora mutevole.

Potrebbe essere stato usato di più se effettivamente rendesse l'oggetto di sola lettura. In C ++ è esattamente ciò che fa const e di conseguenza è una parola chiave molto più utile e molto usata.

Un posto in cui uso pesantemente la parola chiave final è con i parametri per evitare qualsiasi confusione creata da cose come questa:

public void someMethod(FancyObject myObject) {
    myObject = new FancyObject();
    myObject.setProperty(7);
}
...
public static void main(final String[] args) {
    ...
    FancyObject myObject = new FancyObject();
    someOtherObject.someMethod(myObject);
    myObject.getProperty(); // Not 7!
}

In questo esempio sembra ovvio perché questo non funziona, ma se someMethod(FancyObject) è grande e può derivare una complicata confusione. Perché non evitarlo?

Fa anche parte degli standard di codifica Sun (o Oracle ora indovinato).

Sono d'accordo che la parola chiave final migliora la leggibilità. Rende molto più facile capire quando un oggetto è immutabile. Tuttavia, in Java è estremamente prolisso, in particolare (a mio parere) se utilizzato su parametri. Questo non vuol dire che le persone non dovrebbero usarlo perché è prolisso, ma piuttosto non lo usano perché è prolisso.

Qualche altra lingua, come scala, rende molto più facile fare dichiarazioni finali ( val ). In queste lingue, le dichiarazioni finali possono essere più comuni delle variabili.

Si noti che ci sono molti diversi usi della parola chiave finale. Il tuo post copre principalmente gli articoli 2 e 3.

1. Classi finali (JLS 8.1.1.2)
2. Campi finali (JLS 8.3.1.2)
3. Metodi finali (JLS 8.4.3.3)
4. Variabili finali (JLS 4.12.4)

Bene, per cominciare, le convenzioni ufficiali in Java Code non favoriscono né proibiscono l'uso particolare di% codice%. Cioè, gli sviluppatori JDK sono liberi di scegliere il modo in cui preferiscono.

Non riesco a leggere la loro opinione, ma per me la preferenza sull'utilizzo di final o meno è stata una questione di concentrazione. Una questione di se ho abbastanza tempo per concentrarmi completamente sul codice o no .

• Supponiamo che, in uno dei miei progetti, potremmo permetterci di trascorrere un giorno medio su 100 linee di codice simili. In questo progetto, ho avuto una percezione distinta di final come una spazzatura che oscura solo le cose che sono già espresse abbastanza chiaramente nel codice. Sembra che anche gli sviluppatori JDK rientrino in quella categoria.
  
  D'altra parte, era totalmente opposto in un altro progetto, in cui spendevamo una media ora su 100 righe di codice. Lì mi sono ritrovato a sparare final come una mashine gun nel mio e nel codice di altri - semplicemente perché era il modo più rapido per rilevare l'intento del ragazzo che lo ha scritto prima di me e, analogamente, il modo più veloce per comunicare il mio proprio intento al ragazzo che lavorerà sul mio codice più tardi.

It may also provide a little boost to the JIT, and while that's a very limited one, it can't harm

Il ragionamento come sopra è sfuggente. L'ottimizzazione prematura può danneggiare; Donald Knuth si spinge fino a chiamarlo "la radice di tutti i mali" . Non lasciarti intrappolare. Scrivi codice stupido .

Recentemente ho scoperto la gioia della funzione "Salva azioni" in Eclipse IDE. Posso forzarlo a riformattare il mio codice, inserire le annotazioni @Override mancanti e fare alcune cose buone come rimuovere le parentesi inutili nelle espressioni o mettere% parola chiave% ovunque automaticamente ogni volta che clicco final . Ho attivato alcuni di questi trigger e, ragazzo, mi aiuta molto!

È emerso che molti di questi trigger comportano un rapido controllo del mio codice.

• intendevo sovrascrivere un metodo ma l'annotazione non è stata visualizzata quando ho premuto ctrl + S ? - Forse ho rovinato i tipi di parametro da qualche parte!
• Alcune parentesi sono state rimosse dal codice al salvataggio? - Forse quell'espressione logica è troppo difficile per un programmatore per andare in giro velocemente. Altrimenti, perché dovrei aggiungere quelle parentesi in un primo momento?
• Questo parametro o variabile locale non è ctrl + s . ha per cambiare il suo valore?

Si è scoperto che meno variabili cambiano il minor numero di problemi che ho al momento del debug. Quante volte stavi seguendo il valore di qualche variabile solo per scoprire che in qualche modo cambia da say 5 a 7? "Come diavolo potrebbe essere ?!" ti chiedi e trascorri un paio d'ore dopo, entrando e uscendo da innumerevoli metodi per scoprire che hai sbagliato nella tua logica. E per risolverlo devi aggiungere un altro flag, un paio di condizioni e modificare attentamente alcuni valori qua e là.

Oh, odio il debugging! Ogni volta che eseguo il debugger mi sembra che il mio tempo stia finendo e io disperatamente ho bisogno di quel tempo per rendere almeno alcuni dei miei sogni d'infanzia per diventare vero! Al diavolo il debugging! final s significa che non ci sono cambiamenti di valore più misteriosi. Più final s = > parti meno fragili nel mio codice = > meno bug = > più tempo per fare cose buone!

Per quanto riguarda le classi e i metodi di final non mi interessa davvero. Adoro il polimorfismo. Polymorphism significa riutilizzo significa meno codice significa meno bug. JVM fa un ottimo lavoro con la devirtualizzazione e l'inlining del metodo in ogni caso, quindi non vedo un valore nelle possibilità di uccidere il riutilizzo del codice per vantaggi di prestazioni non corretti.

Vedere tutti quei final s nel codice in un primo momento distrae e richiede tempo per abituarsi. Alcuni dei miei compagni di squadra continuano a essere molto sorpresi nel vedere così tante parole chiave%% di% di parole. Vorrei che ci fosse un'impostazione nell'IDE per la colorazione della sintassi speciale per esso. Sarei felice di passare ad una certa sfumatura di grigio (come le annotazioni) in modo che non diventino troppo fastidiosi durante la lettura del codice. Attualmente Eclipse ha un colore separato per final e tutte le altre parole chiave, ma non per final .