imported>Lu12r: /* growthexperiments-addlink-summary-summary:3|0|0 */

2024-09-26T09:42:52Z

growthexperiments-addlink-summary-summary:3|0|0

Neue Seite

{{Belege fehlen|2=Einige Teile dieses Artikels|Plural=1}}

Als '''Dependency Injection''' ('''DI''', {{enS|dependency}} ‚Abhängigkeit‘ und ''{{lang|en|injection}}'' ‚Injektion‘, {{deS|Abhängigkeitsinjektion}}<ref>[https://docs.microsoft.com/de-de/aspnet/core/fundamentals/dependency-injection Dependency Injection in ASP.NET Core], Microsoft Docs</ref> oder ''Einbringen von Abhängigkeiten'') wird in der [[Objektorientierte Programmierung|objektorientierten Programmierung]] ein [[Entwurfsmuster]] bezeichnet, welches die Abhängigkeiten eines [[Objekt (Programmierung)|Objekts]] zur [[Laufzeit (Informatik)|Laufzeit]] reglementiert: Benötigt ein Objekt beispielsweise bei seiner Initialisierung ein anderes Objekt, ist diese Abhängigkeit an einem zentralen Ort hinterlegt – es wird also nicht vom initialisierten Objekt selbst erzeugt.

== Wortbedeutung ==
Die Bezeichnung Dependency Injection wurde 2004 vom Softwareentwickler [[Martin Fowler]] eingeführt, um den damaligen Begriff [[Inversion of Control]] zu präzisieren: {{"|Sprache=en|Text=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.|Autor=Martin Fowler|Quelle=martinfowler.com}}<ref name="fowler-2004">Martin Fowler: [https://martinfowler.com/articles/injection.html Inversion of Control Containers and the Dependency Injection pattern.] 23. Januar 2004 (englisch) abgerufen am 16. Mai 2013.</ref>

== Hintergründe ==
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 [[Klasse (Objektorientierung)|Klassen]] in eine zentrale [[Komponente (Software)|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 [[Compiler|Kompilieren]] vermeiden und erleichtert besonders die Erstellung von [[Unit-Test]]s.

== Vorteile und Nachteile ==

=== Vorteile ===

* 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 [[Stub (Programmierung)|Stubs]] oder Scheinobjekte verwendet werden, die andere [[Objekt (Programmierung)|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-Code|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 [[Softwareentwickler|Entwickler]] können unabhängig voneinander Klassen entwickeln, die sich gegenseitig verwenden, während sie nur die Schnittstelle kennen müssen, über die die [[Klasse (Objektorientierung)|Klassen]] kommunizieren. [[Plug-in]]s 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.

=== Nachteile ===

* 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 [[Softwareentwickler|Entwickler]] auf weitere Dateien verweisen müssen, um die Leistung eines Systems zu verfolgen.
* Dependency Injection Frameworks werden mit [[Reflexion (Programmierung)|Reflexion]] oder [[Dynamische Programmiersprache|dynamischen Programmiersprachen]] implementiert. Dies kann die Verwendung der [[Integrierte Entwicklungsumgebung|IDE]]-Automatisierung behindern, z. B. „Referenzen finden“, „Anrufhierarchie anzeigen“ und sichere [[Refactoring]]s. 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 [[Klasse (Objektorientierung)|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.<ref>[https://dzone.com/articles/how-dependency-injection-di-works-in-spring-java-a How Dependency Injection (DI) Works In Spring Java Application Development.] DZone</ref>

== Struktur ==
[[Datei:W3sDesign Dependency Injection Design Pattern UML.jpg|mini|Ein Beispiel für ein UML-[[Klassendiagramm]] und [[Sequenzdiagramm]] für das Dependency-Injection-[[Entwurfsmuster]].|alternativtext=|700x700px]]

Im UML-[[Klassendiagramm]] instanziiert die Client-Klasse, für die die [[Objekt (Programmierung)|Objekte]] ''ServiceA'' und ''ServiceB'' erforderlich sind, die [[Klasse (Objektorientierung)|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 [[Objekt (Programmierung)|Objekte]] ''ServiceA1'' und ''ServiceB1''. Danach erstellt der ''Injector'' das ''Client''-Objekt und injiziert die Objekte ''ServiceA1'' und ''ServiceB1''.

== Umsetzung ==
[[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 ''{{lang|en|Forms of Dependency Injection}}'' in<ref name="fowler-2004" />). Alle von ihm geschilderten Verfahrensweisen verwenden dabei Methodenaufrufe, bei denen die zu setzenden Abhängigkeiten nicht [[Rückgabewert]]e, sondern [[Parameter (Informatik)|Parameter]] sind.

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

<syntaxhighlight lang="java">
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);
}
}
</syntaxhighlight>

=== Interface Injection ===
Das Modul der injizierenden Klasse definiert eine [[Schnittstelle (Objektorientierung)|Schnittstelle]], die von abhängigen Klassen implementiert werden muss, um zur Laufzeit die Abhängigkeiten zur Verfügung gestellt zu bekommen.

<syntaxhighlight lang="java">
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);
}
}
</syntaxhighlight>

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

<syntaxhighlight lang="java">
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);
}
}
</syntaxhighlight>

=== Weitere Umsetzungsmöglichkeiten ===
Es ist auch möglich, Dependency Injection auf andere Weisen<ref>Ben Yu: {{Webarchiv |url=http://yan.codehaus.org/Dependency+Injection+Types |text=Dependency Injection Types. |wayback=20060430041354 }} (englisch) abgerufen am 16. Mai 2013.</ref> umzusetzen, wie sie in manchen Frameworks Verwendung finden. Beispielsweise können Abhängigkeiten nach Möglichkeiten der Programmiersprache durch [[Reflexion (Programmierung)|Reflexion]] oder durch direktes Setzen des Verweises darauf in den Speicher auch ohne Methodenaufrufe gesetzt werden.

Es existieren verschiedene [[Framework]]s für diverse [[Programmiersprache]]n und [[Plattform (Computer)|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. [[Integrierte Entwicklungsumgebung|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.<ref name="parry-2010">Chad Parry: [https://blacksheep.parry.org/wp-content/uploads/2010/03/DIY-DI.pdf DIY-DI] (PDF; 549 kB) 9. März 2010. (englisch) abgerufen am 29. Juni 2014.</ref>

== Einzelnachweise ==
<references />

{{Navigationsleiste Entwurfsmuster}}

[[Kategorie:Objektorientierte Programmierung]]

Dependency Injection - Versionsgeschichte

imported>Lu12r: /* growthexperiments-addlink-summary-summary:3|0|0 */