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

Ziehen Sie die Komposition der Vererbung vor, da sie flexibler ist und später leicht geändert werden kann, aber verwenden Sie nicht den Ansatz "Komposition immer". Bei der Komposition ist es einfach, das Verhalten mit Dependency Injection / Setters zu ändern. Die Vererbung ist starrer, da die meisten Sprachen nicht zulassen, dass man von mehr als einem Typ ableitet. Die Gans ist also mehr oder weniger gegessen, sobald man von TypA ableitet.

Meine Nagelprobe für die obigen Ausführungen ist:

• Möchte TypB die vollständige Schnittstelle (alle öffentlichen Methoden) von TypA offenlegen, so dass TypB dort verwendet werden kann, wo TypA erwartet wird? Zeigt an Vererbung .

  • Ein Cessna-Doppeldecker wird z. B. die gesamte Schnittstelle eines Flugzeugs aufweisen, wenn nicht mehr. Das macht es also geeignet, von Airplane abzuleiten.

• Möchte TypB nur einen Teil des Verhaltens von TypA? Zeigt den Bedarf an Zusammensetzung.

  • Ein Vogel braucht z.B. nur das Flugverhalten eines Flugzeugs. In diesem Fall ist es sinnvoll, es als Schnittstelle / Klasse / beides zu extrahieren und es zu einem Mitglied beider Klassen zu machen.

Aktualisierung: Ich bin gerade noch einmal auf meine Antwort zurückgekommen, und es scheint, dass sie unvollständig ist, wenn man nicht ausdrücklich auf Barbara Liskovs Liskov-Substitutionsprinzip als Test für "Soll ich von diesem Typ erben?

Answer 2

Betrachten Sie die Eindämmung als eine hat eine Beziehung. Ein Auto "hat einen" Motor, eine Person "hat einen" Namen, usw.

Betrachten Sie die Vererbung als eine ist eine Beziehung. Ein Auto "ist" ein Fahrzeug, ein Mensch "ist" ein Säugetier, usw.

Dieser Ansatz ist nicht mein Verdienst. Ich habe ihn direkt aus dem Zweite Ausgabe von Code Complete por Steve McConnell , Abschnitt 6.3 .

Answer 3

Wenn Sie den Unterschied verstehen, ist es einfacher zu erklären.

Verfahrenskodex

Ein Beispiel dafür ist PHP ohne die Verwendung von Klassen (insbesondere vor PHP5). Die gesamte Logik ist in einer Reihe von Funktionen kodiert. Sie können andere Dateien mit Hilfsfunktionen usw. einbinden und Ihre Geschäftslogik ausführen, indem Sie Daten in Funktionen weitergeben. Das kann sehr schwer zu handhaben sein, wenn die Anwendung wächst. PHP5 versucht hier Abhilfe zu schaffen, indem es mehr objektorientiertes Design bietet.

Vererbung

Dadurch wird die Nutzung von Klassen gefördert. Die Vererbung ist einer der drei Grundsätze des OO-Designs (Vererbung, Polymorphie, Kapselung).

class Person {
   String Title;
   String Name;
   Int Age
}

class Employee : Person {
   Int Salary;
   String Title;
}

Das ist Vererbung bei der Arbeit. Der Mitarbeiter "ist eine" Person oder erbt von einer Person. Alle Vererbungsbeziehungen sind "is-a"-Beziehungen. Employee erbt auch die Eigenschaft Title von Person, d. h. Employee.Title gibt den Titel für den Mitarbeiter und nicht für die Person zurück.

Zusammensetzung

Die Komposition wird der Vererbung vorgezogen. Um es ganz einfach auszudrücken, würden Sie haben:

class Person {
   String Title;
   String Name;
   Int Age;

   public Person(String title, String name, String age) {
      this.Title = title;
      this.Name = name;
      this.Age = age;
   }

}

class Employee {
   Int Salary;
   private Person person;

   public Employee(Person p, Int salary) {
       this.person = p;
       this.Salary = salary;
   }
}

Person johnny = new Person ("Mr.", "John", 25);
Employee john = new Employee (johnny, 50000);

Die Komposition ist in der Regel eine "hat eine" oder "verwendet eine" Beziehung. Hier hat die Klasse Employee eine Person. Sie erbt nicht von Person, sondern bekommt stattdessen das Person-Objekt übergeben, weshalb sie "has a" Person ist.

Komposition über Vererbung

Angenommen, Sie möchten einen Managertyp erstellen, so dass Sie am Ende Folgendes erhalten:

class Manager : Person, Employee {
   ...
}

Dieses Beispiel wird gut funktionieren, aber was wäre, wenn Person und Employee beide als Title ? Sollte Manager.Title "Manager of Operations" oder "Mr." zurückgeben? Unter Komposition ist diese Mehrdeutigkeit besser aufgehoben:

Class Manager {
   public string Title;
   public Manager(Person p, Employee e)
   {
      this.Title = e.Title;
   }
}

Das Objekt Manager besteht aus einem Mitarbeiter und einer Person. Das Verhalten "Titel" wird von "Mitarbeiter" übernommen. Durch diese explizite Zusammensetzung wird unter anderem die Mehrdeutigkeit beseitigt, und Sie werden weniger Bugs finden.

Answer 4

Bei all den unbestreitbaren Vorteilen, die eine Erbschaft mit sich bringt, sind hier auch einige Nachteile aufgeführt.

Nachteile der Vererbung:

1. Sie können die von Superklassen geerbte Implementierung zur Laufzeit nicht ändern (da die Vererbung offensichtlich zur Kompilierzeit definiert wird).
2. Vererbung setzt eine Unterklasse den Details der Implementierung ihrer Elternklasse aus. Deshalb wird oft gesagt, dass Vererbung die Kapselung bricht (in dem Sinne, dass man sich wirklich nur auf die Schnittstellen und nicht auf die Implementierung konzentrieren muss, so dass die Wiederverwendung durch Unterklassen nicht immer vorzuziehen ist).
3. Durch die enge Kopplung, die durch die Vererbung entsteht, ist die Implementierung einer Unterklasse sehr stark an die Implementierung einer Oberklasse gebunden, so dass jede Änderung in der übergeordneten Implementierung die Unterklasse zur Änderung zwingt.
4. Eine übermäßige Wiederverwendung durch Unterklassenbildung kann den Vererbungsstapel sehr tief und auch sehr unübersichtlich machen.

Andererseits Zusammensetzung der Objekte wird zur Laufzeit durch Objekte definiert, die Referenzen auf andere Objekte erwerben. In einem solchen Fall können diese Objekte niemals auf die geschützten Daten des jeweils anderen zugreifen (keine Unterbrechung der Kapselung) und sind gezwungen, die Schnittstelle des jeweils anderen zu respektieren. Und auch in diesem Fall sind die Implementierungsabhängigkeiten viel geringer als bei der Vererbung.

Answer 5

Ein weiterer, sehr pragmatischer Grund, Komposition der Vererbung vorzuziehen, hat mit Ihrem Domänenmodell und dessen Abbildung auf eine relationale Datenbank zu tun. Es ist wirklich schwierig, die Vererbung auf das SQL-Modell abzubilden (man endet mit allen möglichen hacky Workarounds, wie dem Erstellen von Spalten, die nicht immer verwendet werden, der Verwendung von Views usw.). Einige ORMLs versuchen, dieses Problem zu lösen, aber es wird immer schnell kompliziert. Komposition kann leicht durch eine Fremdschlüsselbeziehung zwischen zwei Tabellen modelliert werden, aber Vererbung ist viel schwieriger.