Composizione su eredità ma

Sto cercando di insegnare a me stesso l'ingegneria del software e trovo alcune informazioni contrastanti che mi confondono.

Ho imparato OOP e quali sono le classi / interfacce astratte e come usarle, ma poi sto leggendo che si dovrebbe "favorire la composizione sull'eredità". Capisco la composizione quando una classe compone / crea un oggetto di un'altra classe per utilizzare / interagire con la funzionalità di quel nuovo oggetto.

Quindi la mia domanda è ... dovrei non usare classi e interfacce astratte? Non creare una classe astratta ed estendere / ereditare la funzionalità di quella classe astratta nelle classi concrete e invece comporre nuovi oggetti per usare la funzionalità dell'altra classe?

Oppure, dovrei usare la composizione E l'ereditarietà da classi astratte; li usi entrambi insieme? In tal caso, potresti fornire alcuni esempi di come funzionerebbe e dei suoi benefici?

Dato che mi sento più a mio agio con PHP, lo sto usando per migliorare le mie abilità OOP / SE prima di passare ad altre lingue e trasferire le mie abilità SE appena acquisite, quindi gli esempi che usano PHP sarebbero apprezzati.

Composizione su ereditarietà significa che quando si desidera riutilizzare o estendere la funzionalità di una classe esistente, spesso è più appropriato creare un'altra classe che "avvolga" la classe esistente e ne utilizzi l'implementazione internamente. Il motivo decorativo è un esempio di questo.

L'ereditarietà non è un buon modo predefinito per gestire gli scenari di riutilizzo perché spesso si desidera utilizzare solo una parte della funzionalità di una classe di base e la sottoclasse non può supportare l'intero contratto della classe di base in un modo che soddisfi la sostituzione di Liskov principio .

Il metodo modello è un buon esempio di un caso in cui l'ereditarietà è appropriata.

Vedi questa risposta per le linee guida su come scegliere tra composizione ed eredità.

Non ho abbastanza familiarità con PHP per darvi esempi concreti in quella lingua, ma ecco alcune linee guida che ho trovato utili.

Le interfacce / tratti sono utili per definire il comportamento in molte classi che potrebbero avere ben poco altro in comune.

Ad esempio, se si sta lavorando su un'API JSON, è possibile definire un'interfaccia che specifica due metodi: "toJson" e "toStatusCode". Ciò consentirebbe di scrivere un helper che può prendere qualsiasi oggetto che implementa questa interfaccia e convertirlo in una risposta Http.

Il più delle volte, è preferibile dirigere l'eredità, perché è meno probabile che soffra del fragile problema della classe base, poiché tende a gerarchie di classi superficiali.

L'ereditarietà diretta è meglio pensata come qualcosa che fai quando ci sono validi motivi per farlo, piuttosto che qualcosa che fai a meno che non ci siano validi motivi per non farlo.

Nei linguaggi che non supportano implementazioni predefinite nelle interfacce, può essere un modo ragionevole per condividere un set di funzionalità di base, ma di solito limita fortemente ciò che è possibile fare con le sottoclassi (l'ereditarietà multipla, quando disponibile, raramente vale la pena) . Spesso, trovo che valga la pena di scrivere i metodi di reindirizzamento della piastra di comando per utilizzare la composizione.

La composizione dovrebbe essere la tua strategia predefinita. Per quanto possibile, componi le interfacce e passale come argomenti del costruttore. Questo renderà la tua vita molto più semplice quando scrivi i test.

Evita il più possibile di lavorare con i singoli punti di riferimento globali, poiché confrontare l'output atteso e quello effettivo è un problema se una parte dell'output dipende dallo stato del clock di sistema.

Questo, ovviamente, non è sempre possibile. Ad esempio, il framework Web Play fornisce una libreria JSON che è fondamentalmente una lingua specifica del dominio. La modifica di questo sarebbe un'impresa importante, di cui, la sostituzione delle chiamate a "Json.prettyPrint" sarebbe solo una parte molto minore.

La composizione è quando una classe offre alcune funzionalità istanziando una classe (possibilmente interna) che già implementa questa funzionalità, invece di ereditare da quella classe.

Quindi, ad esempio, se hai una classe che modella una nave e ora ti viene detto che la tua nave dovrebbe offrire un eliporto, non è naturale derivare la tua nave da un eliporto, (duh!), Invece, dovresti avere la tua nave contiene una classe eliporto ed esponila con un Ship.getHelipad()metodo.

Negli anni (circa un decennio fa) le persone erano solite considerare l'eredità come un modo semplice e veloce per aggregare la funzionalità, quindi c'erano molti esempi del tipo di "nave che eredita dall'eliporto", che erano, ovviamente, molto zoppi.

Ma il detto "Favor Composizione sull'ereditarietà" è stato attentamente formulato per chiarire che questo è solo un suggerimento, non una regola. L'autore del detto è stato abbastanza attento da astenersi dal dire qualcosa del tipo " non userai mai l' eredità, solo la composizione". Ciò sta sostanzialmente portando all'attenzione della comunità dell'ingegneria del software il fatto che l'ereditarietà è stata abusata, mentre in molti casi la composizione produce disegni più chiari, eleganti e sostenibili dell'eredità.

Quindi, in sostanza, il detto "Favor Composizione sull'ereditarietà" suggerisce che ogni volta che ti trovi di fronte a "ereditare o comporre?" domanda, dovresti pensare a fondo qual è la strategia più adatta e che la maggior parte delle probabilità è che la strategia più adatta si traduca in composizione, non ereditarietà.

Ma poiché questa non è una regola, dovresti anche tenere presente che ci sono molti casi in cui l'eredità è più naturale. Se usi la composizione lì dove avresti dovuto usare l'eredità, molti mali ricadranno sul tuo codice.

Per tornare all'esempio della nave, se la tua nave ha bisogno di offrire un'interfaccia per interagire con una FloatingMachine, allora è più naturale derivarla da una FloatingMachineclasse astratta , che molto probabilmente potrebbe a sua volta derivare da un'altra Machineclasse astratta .

Ecco la regola empirica per la risposta alla composizione rispetto alla domanda di eredità:

La mia classe ha una relazione "is a" con l'interfaccia che deve esporre? Se sì, usa l'ereditarietà. In caso contrario, utilizzare la composizione.

Una nave "è una" macchina galleggiante e una macchina galleggiante "è una" macchina. Quindi, l'eredità va benissimo per quelli. Ma una nave non è, ovviamente, un eliporto. Quindi è meglio comporre la funzionalità dell'eliporto.