Prinzipien für den objektorientierten Entwurf - Architektur und Entwurfsmuster der Softwaretechnik - page 28

Das folgende Bild zeigt ein Beispiel dafür, dass eine Klasse einer höheren Ebene ein
Interface als Abstraktion aggregiert und eine Klasse der tieferen Ebene diese Abstrak-
tion implementiert:

Höhere Klasse Interface

Tiefere Klasse

Bild 1-12 Architektur zur Erzeugung von Dependency Inversion in einer Hierarchie

Klassen einer höheren Ebene sollen also nicht durch die direkte Verwendung von
Klassen einer tieferen Ebene von diesen abhängen. Dies ist im Bild 1-12 noch nicht
ganz offensichtlich: Über die Aggregation ist die höhere Klasse zunächst vom Interface
abhängig.

Nur wenn die höhere Klasse das Interface (die Abstraktion) selbst
vorgibt, ist sie davon unabhängig, da sie quasi Eigentümerin des
Interface ist. Dadurch wird das Interface auf die höhere Ebene
gehoben und die verbleibenden Abhängigkeiten sind alle von un-
ten nach oben gerichtet.

Durch diese Umkehrung der Abhängigkeiten ist nun auch eine einfache Wieder-
verwendung von Elementen einer höheren Ebene möglich, da sie nicht mehr von
Elementen tieferer Ebenen abhängen. Außerdem können auch Klassen höherer
Ebenen einfach unter Verwendung von Mock-Objekten 13 getestet werden, da die
untere Schicht komplett ausgetauscht werden kann, ohne die höhere Schicht zu beein-
flussen.

1.9.2 Inversion of Control

Bei Inversion of Control wird die Kontrolle umgedreht . Dabei wird ebenfalls eine Um-
kehrung der Abhängigkeiten erreicht. Anders als beim Dependency Inversion-Prinzip
kann durch Inversion of Control eine Umkehrung der Abhängigkeiten auch zwischen
zwei Objekten der gleichen Ebene erreicht werden.

13 Mock-Objekte bilden echte Objekte beim Testen nach. Während ein Stub-Objekt allgemein nur zeigt,
dass die Aufruf-Schnittstelle erfüllt ist und beim Testen irgendwelche Dummy-Daten liefert, erzeugt
ein Mock-Objekt zu einem Testfall passende Daten, die aber keine echten Daten sind.