L'ho visto solo sulle classi wrapper di Java ( String , Integer , ecc.), ma mai in progetti open-source, e non mi è mai stato insegnato in nessun libro o classe. So che significa che la classe non può essere estesa, ma non so quando sarebbe utile per qualsiasi classe al di fuori delle suddette classi JVM-low. Quindi, quando dovrei usare il modificatore final su una classe, se mai?
Ogni volta che non vuoi che la classe sia estesa. La progettazione per l'estensione ha un costo (vedi anche Blog di Eric Lippert: Perché molte delle classi quadro sono sigillate? ) - devi assicurarti di fornire i giusti ganci per la classe , che le persone possono implementare questi hook senza rompere le cose, che puoi essere ragionevolmente sicuro che le sottoclassi non saranno nefaste (questo è particolarmente importante con classi di linguaggio core come String e Integer ), che i contratti che le superclassi implementano sono chiari (in modo che le sottoclassi non li rompano facilmente).
Ciò richiede lavoro, tempo e pensieri per inserirvi. Non è facile sviluppare una classe che dovrebbe essere estesa. E a volte, sai che non vuoi che venga esteso - che può essere usato per scopi nefandi e causare il caos con la tua implementazione se qualcuno ti passa un% mutabile% co_de piuttosto che immutabile .
E così, rendi le classi String . Non ci può essere% mutabile% co_de, perché è una classe immutabile e la sua finale. Sai quando lo prendi, non sarà cambiato da sotto di te in qualche modo. Puoi salvarlo e accertarti che si comporti come final , sempre - non è possibile creare sottoclassi per renderlo diverso.
Quindi, c'è un po 'di design che alcuni seguono che tutte le classi iniziano come predefinite per essere String . Quante volte hai intenzione di sottoclasse quel DTO? E quando fai vuoi sottoclassi per qualche motivo, dovresti passare un po 'di tempo a pensare alle implicazioni della rimozione del modificatore.
C'è una regola di stile di controllo Design per estensione . Personalmente, mi piace. In ogni classe non final, ogni metodo deve essere uno di:
Questo tipo di ragionamento ti consente quindi di scrivere sottoclassi che sono chiaramente implementate nel modo corretto - fornendo ganci e impedendo alla superclasse di essere rotta dalla sottoclasse, non sapendo di armeggiare in modo inaspettato all'interno di esso. Sebbene, ammettiamolo, questa filosofia progettuale significa che le sottoclassi sono più limitate nella loro flessibilità - ma non possono corrompere lo stato della loro superclasse.
Anche in questo caso, se non sei preparato o non vuoi progettare una classe in modo che possa essere estesa in modo pulito, è meglio progettare la classe in modo che non possa essere esteso a tutti .
Leggi altre domande sui tag programming-practices java class-design final