Dependency Injection

Die Bezeichnung Dependency Injection wurde 2004 vom Softwareentwickler Martin Fowler eingeführt, um den damaligen Begriff Inversion of Control zu präzisieren: “Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various [Inversion of Control] advocates we settled on the name Dependency Injection.” (Martin Fowler: martinfowler.com)^[2]

Mit Dependency Injection ist es möglich – entsprechend dem Single-Responsibility-Prinzip – die Verantwortlichkeit für den Aufbau des Abhängigkeitsnetzes zwischen den Objekten eines Programmes aus den einzelnen Klassen in eine zentrale Komponente zu überführen.

In einem herkömmlichen System objektorientierter Programmierung ist dagegen jedes Objekt selbst dafür zuständig, seine Abhängigkeiten – also benötigte Objekte und Ressourcen – zu verwalten. Dafür muss jedes Objekt einige Kenntnisse seiner Umgebung mitbringen, die es zur Erfüllung seiner eigentlichen Aufgabe normalerweise nicht benötigen würde.

Dependency Injection überträgt die Verantwortung für das Erzeugen und die Verknüpfung von Objekten an eine eigenständige Komponente, wie beispielsweise ein extern konfigurierbares Framework. Dadurch wird der Code des Objektes unabhängiger von seiner Umgebung. Das kann Abhängigkeiten von konkreten Klassen beim Kompilieren vermeiden und erleichtert besonders die Erstellung von Unit-Tests.

• Der Client hat die Flexibilität, konfigurierbar zu sein. Nur das Verhalten des Clients ist festgelegt. Der Client kann auf alles reagieren, was die vom Client erwartete intrinsische Schnittstelle unterstützt.
• Die Konfigurationsdetails eines Systems können in Konfigurationsdateien ausgelagert werden, sodass das System ohne Neukompilierung neu konfiguriert werden kann. Es können separate Konfigurationen für verschiedene Situationen geschrieben werden, die unterschiedliche Implementierungen von Komponenten erfordern. Dies beinhaltet, ohne darauf beschränkt zu sein, Tests.
• Weil keine Änderung des Codeverhaltens erforderlich ist, kann sie als Refactoring auf Legacy-Code angewendet werden. Das Ergebnis sind Clients, die unabhängiger sind und die sich einfacher isoliert testen lassen, indem Stubs oder Scheinobjekte verwendet werden, die andere Objekte simulieren, die nicht getestet werden. Diese einfache Prüfung ist oft der erste Vorteil, der bei der Verwendung der Abhängigkeitsinjektion festgestellt wird.
• Der Client kann das gesamte Wissen über eine konkrete Implementierung entfernen, die er verwenden muss. Dies hilft, den Client von den Auswirkungen von Designänderungen und -fehlern zu isolieren. Es fördert die Wiederverwendbarkeit, Testbarkeit und Wartbarkeit.
• Reduzierung des Boilerplate-Codes in den Anwendungsobjekten, da alle Arbeiten zum Initialisieren oder Einrichten von Abhängigkeiten von einer Anbieterkomponente ausgeführt werden.
• Gleichzeitige oder unabhängige Entwicklung. Zwei Entwickler können unabhängig voneinander Klassen entwickeln, die sich gegenseitig verwenden, während sie nur die Schnittstelle kennen müssen, über die die Klassen kommunizieren. Plug-ins werden oft von Drittanbietern entwickelt, die nicht einmal mit den Entwicklern sprechen, die das Produkt erstellt haben, das die Plug-ins verwendet.
• Die Kopplung zwischen einer Klasse und ihrer Dependency wird verringert.

• Es werden Clients erstellt, deren Konfigurationsdetails vom Konstruktionscode bereitgestellt werden müssen. Dies kann lästig sein, wenn offensichtliche Standardeinstellungen verfügbar sind.
• Das Lesen von Code kann erschwert werden, da sie das Verhalten von der Konstruktion trennt. Dies bedeutet, dass Entwickler auf weitere Dateien verweisen müssen, um die Leistung eines Systems zu verfolgen.
• Dependency Injection Frameworks werden mit Reflexion oder dynamischen Programmiersprachen implementiert. Dies kann die Verwendung der IDE-Automatisierung behindern, z. B. „Referenzen finden“, „Anrufhierarchie anzeigen“ und sichere Refactorings. Der Einsatz von Reflexion kann zudem die Leistung des Programms beeinträchtigen.
• In der Regel ist mehr Entwicklungsaufwand im Voraus erforderlich, da man nicht vorhersagen kann, wann und wo es benötigt wird, sondern anfragen muss, dass es injiziert wird, und dann sicherstellen muss, dass es injiziert wurde.
• Es ist Aufwand erforderlich, aus Klassen heraus und in die Verknüpfungen zwischen Klassen zu gelangen, die möglicherweise nicht immer wünschenswert oder einfach zu verwalten sind.
• Die Abhängigkeit von einem Dependency Injection Framework kann gefördert werden.^[3]

 

Im UML-Klassendiagramm instanziiert die Client-Klasse, für die die Objekte ServiceA und ServiceB erforderlich sind, die Klassen ServiceA1 und ServiceB1 nicht direkt. Stattdessen erstellt eine Injector-Klasse die Objekte und injiziert sie in den Client, wodurch der Client unabhängig davon wird, wie die Objekte erstellt werden.

Das UML-Sequenzdiagramm zeigt die Laufzeitinteraktionen: Das Injector-Objekt erstellt die Objekte ServiceA1 und ServiceB1. Danach erstellt der Injector das Client-Objekt und injiziert die Objekte ServiceA1 und ServiceB1.

Martin Fowler beschreibt drei verschiedene Arten zum Setzen benötigter Referenzen, die er mit dem Begriff Dependency Injection verbindet: Constructor Injection, Interface Injection und Setter Injection (Abschnitt Forms of Dependency Injection in^[2]). Alle von ihm geschilderten Verfahrensweisen verwenden dabei Methodenaufrufe, bei denen die zu setzenden Abhängigkeiten nicht Rückgabewerte, sondern Parameter sind.

Abhängigkeiten von anderen Klassen werden über Konstruktoren zur Verfügung gestellt.

class Abhaengiges {
  private Abhaengigkeit abhaengigkeit;

  //Konstruktor
  public Abhaengiges(final Abhaengigkeit abhaengigkeit) {
    this.abhaengigkeit = abhaengigkeit;
  }
}

class Injizierer {
  void methode() {
    final Abhaengigkeit abhaengigkeit = ... ;
    final Abhaengiges abhaengiges = new Abhaengiges(abhaengigkeit);
  }
}

Das Modul der injizierenden Klasse definiert eine Schnittstelle, die von abhängigen Klassen implementiert werden muss, um zur Laufzeit die Abhängigkeiten zur Verfügung gestellt zu bekommen.

interface Injizierbar {
  void injiziere(final Abhaengigkeit abhaengigkeit);
}

class Abhaengiges implements Injizierbar {
  private final Abhaengigkeit abhaengigkeit;

  public void injiziere(final Abhaengigkeit abhaengigkeit) {
    this.abhaengigkeit = abhaengigkeit;
  }
}

class Injizierer {
  void methode() {
    final Abhaengigkeit abhaengigkeit = ... ;
    final Injizierbar abhaengiges = ... ;
    abhaengiges.injiziere(abhaengigkeit);
  }
}

Die abhängige Klasse stellt Methoden zur Verfügung, die dazu verwendet werden, die Abhängigkeiten zur Verfügung zu stellen.

class Abhaengiges {
  private Abhaengigkeit abhaengigkeit;

  public void setAbhaengigkeit(final Abhaengigkeit abhaengigkeit) {
    this.abhaengigkeit = abhaengigkeit;
  }
}

class Injizierer {
  void methode() {
    final Abhaengiges abhaengiges = ... ;
    final Abhaengigkeit abhaengigkeit = ... ;
    abhaengiges.setAbhaengigkeit(abhaengigkeit);
  }
}

Es ist auch möglich, Dependency Injection auf andere Weisen^[4] umzusetzen, wie sie in manchen Frameworks Verwendung finden. Beispielsweise können Abhängigkeiten nach Möglichkeiten der Programmiersprache durch Reflexion oder durch direktes Setzen des Verweises darauf in den Speicher auch ohne Methodenaufrufe gesetzt werden.

Es existieren verschiedene Frameworks für diverse Programmiersprachen und Plattformen zur Umsetzung, die fertige Lösungen zur Verfügung stellen. Diese implementieren das Muster mit zum Teil umfassender, weiterführender Funktionalität, wie beispielsweise das Einlesen der Konfiguration aus Dateien und deren Prüfung auf formale Korrektheit. Siehe dazu die Liste von Dependency Injection Frameworks.

Nachteilig kann sich je nach verwendetem DI-Framework auswirken, dass Programmlogik in Konfigurationsdateien ausgelagert werden muss, was die Übersichtlichkeit vermindern und die Wartung erschweren kann: die Entwickler müssen nun zum Verstehen des Codes noch die Konfiguration berücksichtigen, welche sich zudem manchen Hilfsmitteln der Codeanalyse (z. B. IDE-unterstütztes Finden von Abhängigkeiten oder Refactoring) entzieht.

Dieser Nachteil lässt sich vermeiden, indem die Dependency Injection ähnlich dem Entwurfsmuster Abstrakte Fabrik ohne die Verwendung eines Frameworks als Teil des Programms selbst implementiert wird. Diese Art der Umsetzung wird „Do-It-Yourself Dependency Injection“, kurz „DIY-DI“ genannt.^[5]

1. ↑ Dependency Injection in ASP.NET Core, Microsoft Docs
2. ↑ ^{a b} Martin Fowler: Inversion of Control Containers and the Dependency Injection pattern. 23. Januar 2004 (englisch) abgerufen am 16. Mai 2013.
3. ↑ How Dependency Injection (DI) Works In Spring Java Application Development. DZone
4. ↑ Ben Yu: Dependency Injection Types. (Memento vom 30. April 2006 im Internet Archive) (englisch) abgerufen am 16. Mai 2013.
5. ↑ Chad Parry: DIY-DI (PDF; 549 kB) 9. März 2010. (englisch) abgerufen am 29. Juni 2014.