Was ist Dependency Injection?

Der Unterschied an einem Beispiel

Eine Klasse zur Rechnungsstellung, die in ihrem Konstruktor selbst einen konkreten Mailversand erzeugt, ist an genau diesen Versand gebunden. Wer sie testet, verschickt Mails. Wer sie in einer anderen Umgebung nutzen will, muss den Quelltext ändern.

Übergibst du stattdessen ein Objekt, das eine Versandschnittstelle erfüllt, entscheidet der Aufrufer. In der Produktion reicht er den echten Versand herein, im Test eine Attrappe, im Englischen Mock oder Fake, die den Aufruf nur aufzeichnet. In Java sieht das so aus:

// Without DI: the class creates its own dependency
class RechnungService {
    private final MailVersand versand = new SmtpMailVersand();
}

// With constructor injection: the caller decides
class RechnungService {
    private final MailVersand versand;

    RechnungService(MailVersand versand) {
        this.versand = versand;
    }
}

// Production and test use the same class
new RechnungService(new SmtpMailVersand());
new RechnungService(new FakeMailVersand());

Das ist der ganze Kern. Alles Weitere, Container, Annotationen, Konfigurationsdateien, ist Bequemlichkeit für den Fall, dass es nicht um zwei, sondern um zweihundert Objekte geht. Den Namen Dependency Injection hat Martin Fowler 2004 in einem Artikel geprägt, der die damals neuen Container für Java verglich.

Constructor, Setter und Field Injection

Bei der Constructor Injection kommen alle Abhängigkeiten über den Konstruktor herein. Das ist die empfohlene Form, weil ein Objekt danach vollständig ist und Felder final sein können. Bleibt eine Abhängigkeit optional, bietet sich Setter Injection an. Von der Field Injection, also der Zuweisung direkt an die Felder, raten die meisten Teams ab, weil sich das Objekt außerhalb des Frameworks nicht mehr ohne Reflexion aufbauen lässt und die Liste der Abhängigkeiten unsichtbar wird.

Was ein DI-Container macht

Ein Container übernimmt das Zusammenstecken. Du registrierst, welche Implementierung für welche Schnittstelle gelten soll, und der Container erzeugt die Objekte, erkennt am Konstruktor, was gebraucht wird, und liefert passende Instanzen. Er verwaltet außerdem die Lebensdauer, also ob ein Objekt einmal pro Anwendung, einmal pro Anfrage oder bei jedem Bedarf neu existiert.

In Java ist Spring der verbreitetste Container, Jakarta EE macht dasselbe über CDI mit der Annotation @Inject. In .NET ist ein Container fest eingebaut, dort heißen die drei Lebensdauern Singleton, Scoped und Transient. Angular und NestJS bringen ebenfalls eigene DI-Systeme mit, in denen Services über den Konstruktor oder die Funktion inject() angefordert werden.

Wo es kippt

Der typische Stolperstein sind Zyklen. Wenn A B braucht und B wiederum A, kommt der Container beim Aufbau nicht weiter. Hier hilft kein Trick, sondern die Frage, welche gemeinsame Aufgabe in eine dritte Klasse gehört.

Nicht jede Abhängigkeit muss injiziert werden. Eine Klasse für ein Datum oder eine Liste erzeugst du weiterhin direkt. Das Prinzip zielt auf alles, was du in einem Test austauschen oder in einer anderen Umgebung anders verdrahten willst, typischerweise Datenbankzugriffe, externe Dienste, Uhrzeit und Konfiguration.