Perché usare 'final' in una classe è davvero così male?

Sto eseguendo il refactoring di un sito Web legacy di PHP OOP.

Sono così tentato di iniziare a usare "final" sulle classi per " make it explicit that the class is currently not extended by anything". Questo potrebbe farti risparmiare un sacco di tempo se vengo a una lezione e mi chiedo se posso rinominare / cancellare / modificare una protectedproprietà o un metodo. Se voglio davvero estendere una classe, posso semplicemente rimuovere la parola chiave finale per sbloccarla per l'estensione.

Vale a dire se vengo a una classe che non ha classi secondarie posso registrare quella conoscenza contrassegnando la classe come finale. La prossima volta che ci arrivo non dovrei cercare nuovamente la base di codice per vedere se ha figli. Risparmiando così tempo durante i refactoring.

Sembra una buona idea per risparmiare tempo ... ma ho letto spesso che le lezioni dovrebbero essere rese "definitive" solo in occasioni rare / speciali.

Forse rovina la creazione di oggetti Mock o ha altri effetti collaterali a cui non sto pensando.

Cosa mi sto perdendo?

Ho letto spesso che le lezioni dovrebbero essere rese "definitive" solo in occasioni rare / speciali.

Chiunque abbia scritto che è sbagliato. Usa finalliberamente, non c'è niente di sbagliato in questo. Documenta che una classe non è stata progettata pensando all'ereditarietà, e questo di solito è vero per tutte le classi per impostazione predefinita: progettare una classe che può essere ereditata in modo significativo richiede più di una semplice rimozione di un finalidentificatore; ci vuole molta cura.

Quindi l'utilizzo finaldi default non è affatto male. In effetti, molte persone propongono che questo dovrebbe essere il valore predefinito, ad esempio Jon Skeet .

Forse rovina la creazione di oggetti Mock ...

Questo è davvero un avvertimento, ma puoi sempre ricorrere alle interfacce se devi deridere le tue classi. Questo è certamente superiore a rendere tutte le classi aperte all'eredità solo allo scopo di deridere.

Se vuoi lasciare una nota a te stesso che una classe non ha sottoclassi, allora fallo e usa un commento, ecco a cosa servono. La parola chiave "finale" non è un commento e usare parole chiave in lingua solo per segnalarti qualcosa (e solo tu sapresti mai cosa significhi) è una cattiva idea.

C'è un bell'articolo su "Quando dichiarare le classi finali" . Alcune citazioni da esso:

TL; DR: crea sempre le tue classi final, se implementano un'interfaccia, e non sono definiti altri metodi pubblici

Perché devo usare final?

1. Prevenire la massiccia catena ereditaria del destino
2. Composizione incoraggiante
3. Forza lo sviluppatore a pensare all'API pubblica dell'utente
4. Forza lo sviluppatore a ridurre l'API pubblica di un oggetto
5. Una finalclasse può sempre essere resa estensibile
6. extends rompe l'incapsulamento
7. Non hai bisogno di quella flessibilità
8. Sei libero di cambiare il codice

Quando evitare final:

Le classi finali funzionano efficacemente solo con le seguenti ipotesi:

1. C'è un'astrazione (interfaccia) implementata dalla classe finale
2. Tutta l'API pubblica della classe finale fa parte di tale interfaccia

Se manca una di queste due pre-condizioni, probabilmente raggiungerai un momento in cui renderai la classe estensibile, poiché il tuo codice non si basa davvero sulle astrazioni.

PS Grazie a @ocramius per l'ottima lettura!

"final" per una classe significa: vuoi una sottoclasse? Vai avanti, elimina la sottoclasse "finale" quanto vuoi, ma non lamentarti se non funziona. Sei da solo.

Quando una classe può essere sottoclassata, è il comportamento su cui gli altri si basano, deve essere descritto in termini astratti a cui le sottoclassi obbediscono. I chiamanti devono essere scritti per aspettarsi una certa variabilità. La documentazione deve essere scritta con cura; non puoi dire alla gente "guarda il codice sorgente" perché il codice sorgente non è ancora lì. Questo è tutto sforzo. Se non mi aspetto che una classe sia sottoclassata, è uno sforzo inutile. "final" dice chiaramente che questo sforzo non è stato fatto e dà un equo avvertimento.

Una cosa a cui potresti non aver pensato è il fatto che QUALSIASI cambio di classe significa che deve sottoporsi a nuovi test di qualità.

Non contrassegnare le cose come finali a meno che tu non lo intenda davvero.

L'uso di 'final' toglie la libertà agli altri che vogliono usare il tuo codice.

Se il codice che scrivi è solo per te e non verrà mai rilasciato al pubblico o a un cliente, ovviamente puoi fare con il tuo codice quello che vuoi. Altrimenti, impedisci ad altri di costruire sul tuo codice. Troppo spesso ho dovuto lavorare con un'API che sarebbe stata facile da estendere per le mie esigenze, ma poi sono stato ostacolato da "final".

Inoltre, v'è spesso il codice che dovrebbe meglio non essere fatto private, ma protected. Certo, privatesignifica "incapsulamento" e nascondere cose considerate dettagli di implementazione. Ma come programmatore API potrei anche documentare il fatto che il metodo xyzè considerato come dettaglio di implementazione e, quindi, potrebbe essere modificato / eliminato nella versione futura. Quindi tutti coloro che faranno affidamento su tale codice nonostante l'avvertimento lo stanno facendo a proprio rischio. Ma in realtà può farlo e riutilizzare il codice (si spera già testato) e trovare una soluzione più velocemente.

Naturalmente, se l'implementazione dell'API è open source, si può semplicemente rimuovere il metodo "final" o rendere "protetti" i metodi, ma è necessario modificare il codice e tenere traccia delle modifiche in forma di patch.

Tuttavia, se l'implementazione è chiusa, si rimane indietro con la ricerca di una soluzione alternativa o, nel peggiore dei casi, con il passaggio a un'altra API con meno restrizioni per quanto riguarda le possibilità di personalizzazione / estensione.

Nota che non trovo che 'final' o 'private' siano malvagi, ma penso che vengano usati troppo spesso perché il programmatore non ha pensato al suo codice in termini di riutilizzo ed estensione del codice.