Dependency Inversion Principle (DIP)

Warum?

Punktgenaues Testen setzt Isolation von Klassen voraus. Isolation entsteht, wenn Klassen keine Abhängigkeiten von Implementationen mehr enthalten – weder zur Laufzeit, noch zur Übersetzungszeit. Konkrete Abhängigkeiten sollten deshalb so spät wie möglich entschieden werden. Am besten zur Laufzeit.

Auch das Dependency Inversion Principle (DIP) ist ein SOLID Prinzip. Es besagt folgendes:

• High-Level Klassen sollen nicht von Low-Level Klassen abhängig sein, sondern beide von Interfaces.
• Interfaces sollen nicht von Details abhängig sein, sondern Details von Interfaces.

Verwendet eine High-Level Klasse eine Low-Level Klasse unmittelbar, so ergibt sich eine starke Kopplung zwischen beiden. Spätestens beim Versuch, die High-Level Klasse isoliert zu testen, wird man auf Schwierigkeiten stoßen. Aus diesem Grund sollte die High-Level Klasse von einem Interface abhängig sein, das wiederum von der Low-Level Klasse implementiert wird. So kann die Low-Level Klasse im Unit Test durch ein Mockup ersetzt werden.

Um zur Laufzeit die invertierte, abstrakte Abhängigkeit mit einem konkreten Objekt aufzulösen, bieten sich im Prinzip drei Möglichkeiten:

• mittels Konstruktorparameter „per Hand“
• Einsatz eines Inversion of Control Containers (IoC Container) wie etwa Castle Windsor
• Dependency Lookup

Im gelben Grad injizieren wir die Abhängigkeiten zunächst nur über die Parameter der Konstruktoren. Dies ist anfangs die einfachste Lösung und funktioniert mit einer handvoll Klassen ganz gut. Später im grünen Grad nutzen wir einen IoC Container und Dependency Lookup.