Bevorzugen Sie Komposition statt Vererbung?

Question

Warum Komposition der Vererbung vorziehen? Welche Kompromisse gibt es für jeden Ansatz? Wann sollten Sie Vererbung der Komposition vorziehen?

Answer 1

Während ich in kurzen Worten dem Satz "Lieber Komposition als Erbe" zustimmen würde, klingt das für mich sehr oft wie "lieber Kartoffeln als Coca-Cola". Es gibt Orte für Vererbung und Orte für Komposition. Sie müssen den Unterschied verstehen, dann wird diese Frage verschwinden. Was es für mich wirklich bedeutet, ist "wenn Sie Vererbung verwenden wollen - denken Sie noch einmal nach, wahrscheinlich brauchen Sie Komposition".

Sie sollten Kartoffeln gegenüber Coca-Cola bevorzugen, wenn Sie essen wollen, und Coca-Cola gegenüber Kartoffeln, wenn Sie trinken wollen.

Das Erstellen einer Unterklasse sollte mehr bedeuten als nur eine bequeme Möglichkeit, Methoden der Oberklasse aufzurufen. Sie sollten die Vererbung verwenden, wenn die Unterklasse sowohl strukturell als auch funktionell eine Oberklasse ist, wenn sie als Oberklasse verwendet werden kann und Sie dies auch tun werden. Wenn das nicht der Fall ist, handelt es sich nicht um Vererbung, sondern um etwas anderes. Eine Komposition liegt vor, wenn Ihr Objekt aus einem anderen besteht oder eine Beziehung zu diesem hat.

Für mich sieht es so aus, dass, wenn jemand nicht weiß, ob er eine Erbschaft oder eine Zusammensetzung braucht, das eigentliche Problem darin besteht, dass er nicht weiß, ob er trinken oder essen will. Denken Sie mehr über Ihren Problembereich nach, um ihn besser zu verstehen.

Answer 2

Ich habe hier keine zufriedenstellende Antwort gefunden, also habe ich eine neue geschrieben.

Um zu verstehen, warum " lieber Komposition über Vererbung", müssen wir zunächst die in dieser verkürzten Redewendung weggelassene Annahme zurückgewinnen.

Die Vererbung hat zwei Vorteile: Subtypisierung und Subklassifizierung

1. Subtypisierung bedeutet die Einhaltung einer Typ-(Schnittstellen-)Signatur, d. h. eines Satzes von APIs, und man kann einen Teil der Signatur überschreiben, um Subtyping-Polymorphismus zu erreichen.

2. Unterklassifizierung bedeutet implizite Wiederverwendung von Methodenimplementierungen.

Mit den beiden Vorteilen sind zwei unterschiedliche Zwecke für die Vererbung verbunden: die Orientierung an Subtypen und die Orientierung an der Wiederverwendung von Code.

Wenn die Wiederverwendung von Code das allein Zweck kann die Unterklassifizierung einem mehr geben, als man braucht, d.h. einige öffentliche Methoden der Elternklasse sind für die Kindklasse nicht sehr sinnvoll. In diesem Fall ist die Komposition nicht der Vererbung vorzuziehen, sondern gefordert . Daher rührt auch der Begriff "ist-a" gegenüber "hat-a".

Nur wenn die Subtypisierung bezweckt wird, d. h. wenn die neue Klasse später polymorph verwendet werden soll, stellt sich das Problem der Wahl zwischen Vererbung und Komposition. Dies ist die Annahme, die in dem hier diskutierten verkürzten Idiom weggelassen wird.

Ein Subtyp muss einer Typsignatur entsprechen, d. h. die Komposition muss immer eine gleich große Anzahl von APIs des Typs offenlegen. Jetzt kommen die Kompromisse ins Spiel:

1. Die Vererbung ermöglicht eine unkomplizierte Wiederverwendung von Code, wenn er nicht überschrieben wird, während bei der Komposition jede API neu kodiert werden muss, selbst wenn es sich nur um eine einfache Delegationsaufgabe handelt.

2. Die Vererbung bietet eine unkomplizierte offene Rekursion über die interne polymorphe Stelle this d.h. der Aufruf einer überschreibenden Methode (oder sogar Typ ) in einer anderen Mitgliedsfunktion, entweder öffentlich oder privat (obwohl entmutigt ). Offene Rekursion kann sein simuliert durch Zusammensetzung aber es erfordert zusätzlichen Aufwand und ist nicht immer praktikabel(?). Diese Antwort zu einer duplizierten Frage spricht etwas Ähnliches.

3. Die Vererbung zeigt auf geschützt Mitglieder. Dies unterbricht die Kapselung der übergeordneten Klasse, und wenn sie von einer Unterklasse verwendet wird, wird eine weitere Abhängigkeit zwischen dem Kind und seiner übergeordneten Klasse eingeführt.

4. Die Komposition hat den Vorteil der Inversion der Kontrolle, und ihre Abhängigkeit kann dynamisch injiziert werden, wie in Dekorationsmuster y Proxy-Muster .

5. Die Zusammensetzung hat den Vorteil, dass Kombinatorisch Programmierung, d. h. eine Arbeitsweise wie die zusammengesetztes Muster .

6. Die Zusammensetzung folgt unmittelbar Programmierung an einer Schnittstelle .

7. Die Zusammensetzung hat den Vorteil der einfachen Mehrfachvererbung .

In Anbetracht der oben genannten Abwägungen ergibt sich Folgendes lieber Komposition über Vererbung. Für eng verwandte Klassen, d.h. wenn die implizite Wiederverwendung von Code wirklich von Vorteil ist oder die magische Kraft der offenen Rekursion gewünscht wird, ist die Vererbung die erste Wahl.

Answer 3

Vererbung ist ziemlich verlockend, vor allem wenn man aus dem prozeduralen Bereich kommt, und sieht oft trügerisch elegant aus. Ich meine, alles, was ich tun muss, ist, dieses eine Bit an Funktionalität zu einer anderen Klasse hinzuzufügen, richtig? Nun, eines der Probleme ist, dass

Vererbung ist wahrscheinlich die schlechteste Form der Kopplung, die man haben kann.

Ihre Basisklasse durchbricht die Kapselung, indem sie den Unterklassen Implementierungsdetails in Form von geschützten Mitgliedern preisgibt. Dadurch wird Ihr System starr und anfällig. Der tragischere Fehler ist jedoch, dass die neue Unterklasse das gesamte Gepäck und die Meinung der Vererbungskette mit sich bringt.

Der Artikel, Vererbung ist böse: Das epische Versagen des DataAnnotationsModelBinders geht ein Beispiel für diese Vorgehensweise in C# durch. Es zeigt die Verwendung von Vererbung, wenn Komposition hätte verwendet werden sollen, und wie es refaktorisiert werden könnte.

Answer 4

Wann können Sie die Komposition verwenden?

Sie können immer die Komposition verwenden. In einigen Fällen ist auch die Vererbung möglich und kann zu einer leistungsfähigeren und/oder intuitiveren API führen, aber die Komposition ist immer eine Option.

Wann können Sie die Vererbung nutzen?

Es wird oft gesagt, dass, wenn "a bar is a foo", dann die Klasse Bar kann die Klasse Foo . Leider ist dieser Test allein nicht zuverlässig, verwenden Sie stattdessen den folgenden Test:

1. ein bar ist ein foo, UND
2. Bars können alles, was Foos können.

Der erste Test stellt sicher, dass alle Getter de Foo sinnvoll sein in Bar (= gemeinsame Eigenschaften), während der zweite Test sicherstellt, dass alle Einsteller de Foo sinnvoll sein in Bar (= gemeinsame Funktionalität).

Beispiel: Hund/Tier

Ein Hund ist ein Tier UND Hunde können alles tun, was Tiere tun können (z. B. atmen, sich bewegen usw.). Daher ist die Klasse Dog puede die Klasse erben Animal .

Gegenbeispiel: Kreis/Ellipse

Ein Kreis ist eine Ellipse, ABER Kreise können nicht alles, was Ellipsen können. Zum Beispiel können Kreise nicht gestreckt werden, während Ellipsen dies können. Deshalb ist die Klasse Circle no puede die Klasse erben Ellipse .

Dies wird als die Kreis-Ellipse-Problem was nicht wirklich ein Problem ist, sondern eher ein Hinweis darauf, dass "a bar is a foo" an sich kein zuverlässiger Test ist. Insbesondere zeigt dieses Beispiel, dass abgeleitete Klassen erweitern. die Funktionalität von Basisklassen, niemals einschränken es. Andernfalls könnte die Basisklasse nicht polymorph verwendet werden. Das Hinzufügen des Tests "bars can do everything that foos can do" stellt sicher, dass die polymorphe Verwendung möglich ist, und ist äquivalent zu Liskov-Substitutionsprinzip :

Funktionen, die Zeiger oder Verweise auf Basisklassen verwenden, müssen in der Lage sein, Objekte abgeleiteter Klassen zu verwenden, ohne dies zu wissen

Wann sollten Sie die Vererbung nutzen?

Auch wenn Sie puede Vererbung zu verwenden, bedeutet nicht, dass Sie devrait : Die Verwendung von Komposition ist immer eine Option. Die Vererbung ist ein leistungsfähiges Werkzeug, das die implizite Wiederverwendung von Code und die dynamische Verteilung ermöglicht, aber sie bringt auch einige Nachteile mit sich, weshalb die Komposition oft bevorzugt wird. Die Kompromisse zwischen Vererbung und Komposition sind nicht offensichtlich und werden meiner Meinung nach am besten erklärt in lcn's Antwort .

Als Faustregel neige ich dazu, die Vererbung der Komposition vorzuziehen, wenn die polymorphe Verwendung voraussichtlich sehr häufig vorkommt. In diesem Fall kann die Leistung der dynamischen Abfertigung zu einer viel besser lesbaren und eleganten API führen. Zum Beispiel, eine polymorphe Klasse zu haben Widget in GUI-Frameworks, oder eine polymorphe Klasse Node in XML-Bibliotheken ermöglicht eine API, die viel lesbarer und intuitiver zu verwenden ist als eine Lösung, die nur auf Komposition basiert.

Answer 5

In Java oder C# kann ein Objekt seinen Typ nicht mehr ändern, sobald es instanziiert wurde.

Wenn Ihr Objekt also als ein anderes Objekt erscheinen oder sich abhängig von einem Objektzustand oder Bedingungen anders verhalten soll, dann verwenden Sie Zusammensetzung : Siehe Staat y Strategie Entwurfsmuster.

Wenn das Objekt vom gleichen Typ sein muss, dann verwenden Sie Vererbung oder Schnittstellen implementieren.