Das Composit Reuse Prinzip

Das Composit Reuse Prinzip, das oftmals auch in Form der Empfehlung "Favour composition over inheritance" angeführt wird, ist ein inzwischen fest etabliertes Entwurfsprinzip für objektorientierte Systeme.

Name, Kurzform	Composit Reuse Prinzip
Synonyme	Composit Reuse Principle (CRP), Favour composition over inheritance (FcoI), Komposition an Stelle von Vererbung
Beschreibung	(1) Gängige englische Kurzform: „Favour composition over inheritance“. (2) Ausführlicher: Wiederverwendung sollte durch Komposition erreicht werden, nicht durch Vererbung. (3) Noch ausführlicher: Wiederverwendung sollte durch polymorphe Komposition von Objekten erreicht werden, nicht durch Vererbungsbeziehungen zwischen Klassen.
Erläuterung	Zur Realisierung wiederverwendbarer Software-Elemente stehen im objektorientierten Kontext insbesondere zwei Alternativen zur Verfügung: Nutzung der Vererbung (Whitebox-Reuse). Nutzung der Komposition (Blackbox-Reuse). Mit der Vererbung gehen jedoch eine Reihe von Problemen einher, darunter: Verletzung des Geheimnisprinzips. Beeinträchtigung der Verständlichkeit des Codes, z. B. durch Verletzung des Lokalitätsprinzips. Erschwerung der Veränderbarkeit, insbesondere bei komplexen Vererbungshierarchien. Beeinträchtigung der Zuverlässigkeit (z. B. auf Grund des Fragile Base Class Problems). Eine detaillierte Beschreibung dieser und weiterer Probleme wird in [Hunt2000] wiedergegeben. Mit der Möglichkeit der Komposition steht allerdings eine Wiederverwendungsmöglichkeit zur Verfügung, welche diese Probleme nicht aufweist. Sprechen keine anderen Gründe für die Nutzung einer Vererbungshierarchie als die Wiederverwendung, so sollte die Komposition bevorzugt werden.
Beispiel	Die Komposition wiederverwendbarer Dienstklassen ist in Zeiten von Dependency Injection Frameworks eine Selbstverständlichkeit geworden. Auf ein Quellcode-Beispiel wird daher an dieser Stelle verzichtet.
Historie	Das Kompositum als Entwurfsmuster wird bereits in [GOF95] vorgestellt. Dort liegt der Fokus jedoch noch nicht auf der Vermeidung der Vererbungsbeziehung. Eine ausführliche Beschreibung unter der Bezeichnung Composit Reuse Principle gibt [Knoernschild2002], es bleibt aber unklar, ob das Prinzip hier erstmals unter diesem Namen beschrieben wird. In jüngeren Tagen hat auch die Clean Code-Gemeinde das Prinzip unter dem Kürzel FcoI (Favour Composition over Inheritance) für sich entdeckt.
Art des Prinzips	Grundlegende Einteilung: Produktprinzip. Technologiebezug: Spezifisch. (Objektorientierung). Entwurfsgüte: Strukturprinzip. Handlungsbezug: Erleichterung von Änderung und Wiederverwendung. Kognitionsbezug: Keiner. (Siehe Kategorisierung der Prinzipien.)
Grad der formalen Spezifikation	Gut. Es dürfte allerdings rein syntaktisch kaum zu erkennen sein, ob die Nutzung einer Vererbungsbeziehung primär mit dem Ziel der Wiederverwendung erfolgte.
Vorteile	Erfüllt zahlreiche weitere Prinzipien, darunter  Open Closed Prinzip, da neue Funktionen durch Hinzufügen neuer Dienstobjekte ohne Modifikation bestehenden Codes erreicht werden kann. Prinzip der losen Kopplung, da an die Stelle der relativ engen Kopplung durch die Vererbungsbeziehung die lose Kopplung durch Injektion von Dienstobjekten tritt. Umgehung der Probleme, die im Kontext des Liskovschen Substitutionsprinzip thematisiert werden. Geheimisprinzip (kein Whitebox-Reuse). Simpel umsetzbar, gut unterstützt durch Dependency Injection Frameworks.
Nachteile	Kann im Einzelfall die Umsetzung zahlreicher reiner „Forward-Methoden“ erforderlich machen, deren einziger Zweck die Kapselung der Zugriffe auf das Dienstobjekt ist. Es handelt sich um ein Negativprinzip: Zum reinen Zweck der Wiederverwendung soll Vererbung vermieden werden. Es fehlen aber positive Kriterien, wann Vererbung dennoch einzusetzen ist.
Übergeordnete Prinzipien	Geheimnisprinzip Open Closed Prinzip Prinzip der losen Kopplung
Abgleitete Prinzipien	-
Qualitätsmerkmale	(+) Verständlichkeit, (+) Veränderbarkeit (+) Zuverlässigkeit

Quellen

[GOF95] - Design Patterns, Gamma et. al, 1995
[Hunt2000] – Inheritance Considered Harmful: When to use inheritance and when to use composition, John Hunt, Alex McManus, Fred Long, Edel Sheratt, 2000

[Knoernschild2002] – Java Design, Objects, UML, and Process, Kirk Knoernschild, 2002