Molti livelli di ereditarietà multilivello sono considerati negativi?
Questo è il mio design
BaseFileProcessor
RefundFile Processor inherits BaseFileProcessor (Has n child class)
FailedRefundFile Processor inherits RefundFile (Has n child class)
FailedRefundFile for CardsPayment inherits FailedRefundFile (n child class)
Il yo-yo problem non è semplicemente un esercizio di conteggio dei livelli. Mantenere il numero di livello a 1 solo rende impossibile creare questo particolare problema. È certamente concepibile che quattro livelli di ereditarietà possano esistere in una base di codice ben scritta, facile da capire, che chiama le cose in modo semplice.
Il pericolo è anche se è vero che basta un solo dopy coder per saltare dentro e iniziare a intrecciare le cose in un casino yo-yo che manda il lettore su e giù nello stack dell'ereditarietà.
Ma no, manca completamente il punto di dire "più di tre livelli è cattivo". Comprendere il problema e come attenuarlo. È molto meglio dire "Quando usi l'ereditarietà a più livelli, prenditi un momento e assicurati di non dare inutilmente ai tuoi lettori la cinetosi".
Con un po 'di lavoro in più puoi di solito eliminare la necessità di ereditarietà multi-livello, che può rendere il codice più leggibile. I buoni programmatori sono disposti a fare un piccolo lavoro extra per mantenere leggibile il loro codice. Ma i bravi programmatori comprendono anche la legge dei rendimenti decrescenti. Quindi è davvero una questione di quanto. Non cadere nella trappola di evitare ciecamente questo problema. Finisci per creare problemi diversi.
Sì. Oppure, diciamo "attualmente fuori moda"
Le stesse cose che in passato avrebbero reso questo un design "buono", ovvero il riutilizzo del codice nelle classi ereditate è ora considerato problematico dal punto di vista della manutenzione.
Ad esempio, diciamo che correggo il bug nel BaseFileProcessor. Avrò cambiato il comportamento di ogni classe con esso nella sua catena di ereditarietà.
Se lo sto usando come un modo per estendere la mia logica di business: dire che ho il processore della carta di credito fallito e vari Failed {PaymentMethodGoesHere} Processore (i) Quindi avrei potuto effettuare centinaia di classi e i loro processi aziendali retrospettivi.
Questa è una cosa "buona" per il punto di vista del riutilizzo del codice e potenzialmente la correzione del bug in quelle 100 classi con una sola modifica. Da una prospettiva di gestione del cambiamento è pessimo.
Questo bug potrebbe essere stato segnalato solo contro un singolo tipo di pagamento. Ora ho cambiato un sacco di cose che presumibilmente funzionavano bene. (O almeno senza lamentarsi)
Le imprese amano essere in grado di limitare l'ambito di un cambiamento. Mi viene costantemente chiesto 'Ma questo avrà effetto solo su questo ... giusto?'
Preferirebbero fare 100 piccoli cambiamenti nel tempo rispetto a un big bang con lo stesso scope.
E per una buona ragione! Quando il codice è vecchio di alcuni anni, è stato esteso da diverse persone e chiedono un nuovo assegno per 'aggiustare questo piccolo bug', chi può veramente dire quali saranno gli effetti in tutte quelle classi child?
Tuttavia, dovrei aggiungere un disclaimer. Questo si applica davvero alla "logica del business", che è un po 'un ossimoro.
Se stai scrivendo qualche implementazione tecnica di una funzione spec o di matematica ben definita, una volta completata non cambierà e sarà molto chiaro che cos'è un bug e cosa no. O dire che stai scrivendo un'applicazione unica come un gioco. Dove non tornerai per cambiare le cose dopo il rilascio. Questi argomenti sulla manutenibilità e sulla gestione delle modifiche non si applicano.
Leggi altre domande sui tag design-patterns php