Component Based Development/DI

Zur Klärung der Frage, was Dependency Injection (DI) soll zuerst beschrieben werden, welche Art von Abhängigkeit (Dependency) hiermit gemeint ist.

In DI steht das D für Abhängigkeiten zwischen Klassen bzw. genauer zwischen den korrespondierenden Objekten.

Da in der Regel komplexere Objekte Funktionalitäten anderer Objekte benötigen, haben Sie diese Objekte in Membervariablen (Objektvariablen) gespeichert. z.B. (modifiziert aus M. Fowler: Inversion of Control Containers and the Dependency Injection pattern, 2004 http://martinfowler.com/articles/injection.html) :

Die Methode  verwendet hier ein Objekt von Typ. Man sagt  ist abhängig von.

Der  ist ein Interface, für die es eine Vielzahl von Implementierungen  geben könnte.

Wenn nun aber direkt im Konstruktor des  eine konkrete  -Instanz erzeugt, ist diese Wiederverwertbarkeit nicht gegeben, z.B durch:

Der  ist fest mit einer Implementierung des MovieFinder  verbunden. Dies führt zu einer starken Kopplung. Hierdurch ist aber die Methode  bzw. der  nicht mehr für alle möglichen Ausprägungen (Implementierungen) des   nutzbar. Außerdem lässt sich die Methode  nicht mehr testen, ohne gleichzeitig den   mit zu testen. Ein weiterer Nachteil ist das die Abhängigkeit vom  zum   nicht in den Methoden-Signaturen (denke an Javadoc) erkennbar ist, sondern nur in der Implementierung.

Eine Lösung des Problems ist die Abhängigkeit z4 der 26n2reten 0*3e0ent5er4ng von außen hinein zugeben, z.B. über den Konstruktor (Constructor Injection). Nicht die die Klasse selbst kümmert sich um die Auflösung der konkret genutzten Implementierung des Interface. Sie wird von außen injiziert. Daher der Name "Dependency (Abhängigkeit) Injection (Injizieren)".

Hier wird aus der Konstruktor-Signatur die Abhängigkeit ersichtlich.

Dies ist die Grundlage von Dependency Injection (DI). Dabei ergeben sich folgende Vorteile:
 * Bessere Wiederverwertbarkeit
 * Schwächen der Kopplung zwischen den Komponenten
 * Isoliertes Testen (injizieren von Mock-Objekten) wird möglich
 * Erkennen der Abhängigkeit in der Methoden-, bzw. Konstruktor-Signatur.