Una delle regole per checkstyle con cui ho una relazione amore / odio è Class Design sezione - Progettazione per l'estensione . Spesso mi sono ritrovato a spegnerlo perché è fastidioso seguire una "T", specialmente su grandi progetti legacy in cui non viene seguito (avere un avviso di bajillion dallo stile di controllo rende più difficile correggerli).
Detto questo, è una regola piuttosto semplice:
The exact rule is that nonprivate, nonstatic methods of classes that can be subclassed must
- be abstract or
- be final or
- have an empty implementation.
Se riesci a creare una sottoclasse di una classe, dovresti fare in modo che possa essere esteso in modo significativo.
"Aspetta", dici, "Questa è una regola sui metodi pubblici non statici che devono essere astratti, definitivi o con un'implementazione vuota. Che cosa ha a che fare con una classe finale?"
The exact rule is that non private, non static methods of classes that can be subclassed must ...
Se lasci una lezione non-finale, stai dicendo che può essere sottoclassificata in modo significativo. Se non può, non dovrebbe essere in grado di essere sottoclasse.
Facendo una finale di classe, stai rendendo un po 'più difficile per il tuo collega armeggiare con le sue viscere creando una sottoclasse che esponga tutti i metodi che sono specifici dell'implementazione. Ci sono alcune cose meravigliose come rintracciare un bug perché un immutabile che hai scritto è stato sottoclassato per diventare mutabile - fidati di me su questo.
La progettazione per l'ereditarietà è costosa. Ci vuole un pensiero in più per assicurarti che tu stia facendo bene. Che qualcun altro non lo rovinerà. Dicendo final class
stai evitando tutto questo e dicendo "no - questo non può essere ereditato" e rendendo molto più facile ragionare.
Se sei non che spende il tempo per progettare la classe per l'estensibilità, la cosa appropriata da fare è assicurarsi che nessuno faccia l'errore lavorando dalla convinzione che la classe è estensibile.
Lettura correlata: