Alternativa a "eredità contro composizione?" [duplicato]

Question

Alternativa a "eredità contro composizione?" [duplicato]

#1 da (10 voti)
#2 da (4 voti)

5

Ho colleghi al lavoro che sostengono che "L'ereditarietà è un anti-modello" e che vogliono usare sistematicamente la composizione, tranne che nei casi (rari, secondo loro) in cui l'ereditarietà è davvero il modo migliore per andare.

Voglio suggerire un'alternativa dove continuiamo ad usare l'ereditarietà, ma è severamente vietato (applicato dalle revisioni del codice) di usare qualsiasi cosa tranne i membri pubblici delle classi base nelle classi derivate.

Per un caso in cui non è necessario scambiare componenti di una classe in fase di runtime (ereditarietà statica), sarebbe sufficiente per la composizione? O sto dimenticando qualche altro aspetto importante della composizione?

anti-patterns design design-patterns inheritance

posta Frank 12.11.2012 - 17:59

fonte

2 risposte

4

Penso che la differenza tra le due cose sia nelle loro intenzioni. La classe che stai scrivendo voleva davvero essere usata come sostituzione / specializzazione della sua classe Base o semplicemente usando alcune funzionalità? Se il primo caso è vero, dovresti andare con l'eredità. Se quest'ultimo è vero, vai per composizione. Nella mia esperienza sull'uso dell'ereditarietà laddove la composizione sarebbe appropriata, crea una base di codice più complessa, meno comprensibile e approssimativa.

risposta data 12.11.2012 - 18:56

fonte

Leggi altre domande sui tag anti-patterns design design-patterns inheritance

Non dovrebbe MVC essere MCV? [chiuso] Se python viene compilato per il montaggio e in esso è scritto un sistema operativo, esso competerà favorevolmente con C nei benchmark?

score 10 · Accepted Answer

Stai guardando indietro. La composizione non è preferita a causa di alcuni invisibili vantaggi della composizione, è preferita perché evita gli inconvenienti dell'ereditarietà. L'ereditarietà aggiunge il significativo vantaggio della sostituibilità. Tuttavia, questo vantaggio deriva dal costo significativo dell'accoppiamento stretto. L'ereditarietà è la relazione di accoppiamento più strong possibile. Se non hai bisogno della sostituibilità, il costo del coupling non vale la pena.

La tua versione limitata dell'ereditarietà fa fronte al suo altro costo, una perdita di incapsulamento, ma non fa nulla per il costo molto più significativo di accoppiamento.