Erweiterungen für das CCD Wertesystem

Schon vor einiger Zeit habe ich im CCD Forum zwei Ergänzungen zum Wertesystem zur Diskussion gestellt ([1], [2]). Ich möchte diese hier ausformuliert nochmals präsentieren und werde, sobald ich das der OK Initiatoren habe, diese auch in das Wertesystem einpflegen.

Favouring Composition over Inheritance (FCoI)

Für die Wiederverwendung von Funktionalität bietet die OOP zwei allseits bekannte Möglichkeiten: Vererbung (whitebox-reuse) und Komposition (blackbox - reuse). Bei der Vererbung erbt eine Subklasse von einer Elternklasse und kann diese um Funktionalität erweitern und Verhalten ändern - die Internas der Elternklasse sind sichtbar. Bei der Komposition verwendet eine Klasse eine andere. Sie verwendet also einen externen Dienstleister um etwas zu tun. Dabei müssen die Schnittstellen zu der verwendeten Klasse gut definiert sein, da die Internas nicht sichtbar sind sondern die Komponente als BlackBox verwendet wird.

Beide Varianten bieten ihre Vor- und Nachteile. Vererbung ist sehr einfach einzusetzen und ein effizientes, gut verbreitetes Mittel zur Wiederverwendung von Funktionalität. Vererbung hat also durchaus seine Berechtigung. Leider wird sie aber oft viel zu viel eingesetzt. In vielen Fällen sollte man der Komposition Vorschub gewähren, denn Sie ist flexibler. Bei der Vererbung wird die Subklasse von der Elternklasse abhängig. Oft entstehen schleichend grosse Klassenhierarchien welche bei genaueren Betrachtung häufig LOD (Law of Demeter) und LSP (Liskov Substitution Principle) verletzen. Auch ist es schwierig bei der Vererbung die Funktionalität zur Laufzeit auszutauschen, was bei der Komposition kein Problem ist. Selbst das Anpassen der Funktionalität in grossen Klassenhierarchien wird schnell zum unangenehmen Problem.

"Because inheritance exposes a subclass to details of its parent's
implementation, it's often said that 'inheritance breaks encapsulation".
(Gang of Four 1995:19)

Bei der Komposition ist das gesamte system weniger gekoppelt. Die Komposition kann allerdings auf den ersten Blick schwerer zu verstehen sein.

Deshalb gilt: Vererbung ist keine schlechte Sache. Sie sollte aber mit Bedacht eingesetzt werden und oft sollte die Komposition favorisiert werden.


Information Hiding Principle (IHP)

Eines der effizientesten Mittel zur Bekämpfung von Komplexität ist das reduzieren von Abhängigkeiten auf ein absolutes Minimum. Deshalb halte ich das alte, aber stets aktuelle, Prinzip für sehr wichtig. Gerade zu Zeiten des Contract-First-Designs sollte man sich überlegen, was eine Schnittstelle auch wirklich alles preis geben muss. Es gilt also nicht nur das ISP (Interface Segreation Principle) zu beachten, sondern auch das IHP.

Um die beiden also klar abzutrennen:

ISP besagt: Wenn du nicht immer alle Methoden brauchst, dann verteile sie auf mehrere Interfaces.

IHP besagt: Mache dein Interface nicht unnötig von weiteren Typen abhängig.

So einfach und klar wie das auch sein mag - so gerne hätte ich es explizit im CCD Wertesystem!