Laden...

Composition over Inheritance - sinnvoll ?

Erstellt von Lenny vor 9 Jahren Letzter Beitrag vor 9 Jahren 1.714 Views
L
Lenny Themenstarter:in
95 Beiträge seit 2009
vor 9 Jahren
Composition over Inheritance - sinnvoll ?

Hallo,
ich habe in einem Blog folgenden schönen Artikel gefunden, der auch im Heise Forum bereits diskutiert wurde.

Favor Composition Over Inheritance part 1
Favor Composition Over Inheritance part 2

Dieser Artikel legt nahe, dass Vererbung ein "veraltetes bzw. schlechtes Prinzip" sei und man nur Composition mit Interfaces nutzen sollte.

Allerdings habe ich das Gefühl, der Artikel beschreibt die Realität nur etwas einseitig.
Nun wollte ich von euch wissen wie ihr es damit haltet, bzw ob ihr Vererbung als genauso "böse" anseht wie der Autor ?

Mir geht es in dem Fall nicht um ein spezielles Problem sondern nur um allgemeine Wissenserweiterung.

P
1.090 Beiträge seit 2011
vor 9 Jahren

Vererbung ist grundlegend weder gut noch schlecht. Es kommt aber immer darauf wie man damit umgeht. So wie in dem Beispiel, ist es natürlich schlecht.

Vererbung ist für mich da sinnvoll wo es eine „natürliche“ Verbindung gibt, z.B. das Mitarbeiter und Kunde von Person Erben ist vollkommen in Ordnung. Ich kann dann einen Großteil des Codes für beide schreiben.

Wenn ich eine „künstliche“ Verbindung herstelle ist die Vererbung meistens keine gute Lösung. Z.B. wenn ich Person und Auto von MoveAbel ableite. Damit ich beide Bewegen kann. Hier ist sicher ein Interface eine bessere Lösung.

Vererbung sollte grundlegend aber sparsam eingesetzt werden. Da sie eine der härtesten Kopplungen ist die es gibt. Und möglichst flach gehalten, da tiefe Vererbungen schwer zu verstehen sind. Wenn ich nun Vererbung einsetze sollte ich einfach nochmal ob eine Komposition Komposition besser als ist.

Also 2 mal denken und 1 mal programmieren.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

W
872 Beiträge seit 2005
vor 9 Jahren

Das Grundproblem ist meist, dass zu sehr über eine Hierarchie und zuwenig über das Verhalten nachgedacht wird.
Das problematische in der Hierarchie ist, dass diese sich eher ändert als das Verhalten der Komponenten.
Für OO Design empfehle ich Practival Object-Oriented Design. Ist zwar mit Beispielen in Ruby, aber trotzdem ein sehr gutes Buch...