Was ist Dependency Injection?

Question

Es wurden bereits mehrere Fragen zu folgenden Themen gestellt Dependency Injection wie z. B. wann sie zu verwenden ist und welche Rahmenbedingungen es dafür gibt. Wie auch immer,

Was ist Dependency Injection und wann und warum sollte sie eingesetzt werden?

Answer 1

Die gängigen Antworten sind nicht hilfreich, da sie die Injektion von Abhängigkeiten auf eine Weise definieren, die nicht sinnvoll ist. Einigen wir uns darauf, dass wir mit "Abhängigkeit" ein bereits existierendes anderes Objekt meinen, das unser Objekt X benötigt. Aber wir sagen nicht, dass wir "dependency injection" machen, wenn wir sagen

$foo = Foo->new($bar);

Wir rufen das einfach auf, indem wir Parameter an den Konstruktor übergeben. Das tun wir regelmäßig, seit Konstruktoren erfunden wurden.

"Dependency Injection" wird als eine Art "Umkehrung der Kontrolle" betrachtet, was bedeutet, dass dem Aufrufer ein Teil der Logik entzogen wird. Das ist nicht der Fall, wenn der Aufrufer Parameter übergibt. Wäre dies also DI, würde DI keine Inversion der Kontrolle bedeuten.

DI bedeutet, dass es eine Zwischenebene zwischen dem Aufrufer und dem Konstruktor gibt, die Abhängigkeiten verwaltet. Ein Makefile ist ein einfaches Beispiel für Dependency Injection. Der "Aufrufer" ist die Person, die "make bar" in die Befehlszeile eingibt, und der "Konstruktor" ist der Compiler. Das Makefile gibt an, dass bar von foo abhängt, und es führt eine

gcc -c foo.cpp; gcc -c bar.cpp

vor der Durchführung einer

gcc foo.o bar.o -o bar

Die Person, die "make bar" eingibt, braucht nicht zu wissen, dass bar von foo abhängt. Die Abhängigkeit wurde zwischen "make bar" und gcc injiziert.

Der Hauptzweck der Zwischenebene ist nicht nur die Übergabe der Abhängigkeiten an den Konstruktor, sondern die Auflistung aller Abhängigkeiten in nur ein Ort und sie vor dem Programmierer zu verbergen (und ihn nicht zu zwingen, sie bereitzustellen).

Normalerweise stellt die Zwischenebene Fabriken für die konstruierten Objekte zur Verfügung, die eine Rolle bereitstellen müssen, die jeder angeforderte Objekttyp erfüllen muss. Der Grund dafür ist, dass man durch eine Zwischenebene, die die Details der Konstruktion verbirgt, bereits den Abstraktionsnachteil von Fabriken in Kauf genommen hat, so dass man genauso gut Fabriken verwenden kann.

Answer 2

Aus dem Buch, ' Erfahrener Java-Entwickler: Wichtige Techniken von Java 7 und polyglotter Programmierung

DI ist eine besondere Form von IoC, bei der der Prozess der Suche nach den Abhängigkeiten außerhalb der direkten Kontrolle des aktuell ausgeführten Codes liegt.

Answer 3

Dependency Injection für 5-Jährige.

Wenn Sie für sich selbst Dinge aus dem Kühlschrank holen, können Sie Probleme verursachen. Du könntest die Tür offen lassen, du könntest etwas holen, was Mama oder Papa nicht wollen, dass du es bekommst. Vielleicht suchst du sogar nach etwas, das wir gar nicht haben oder das abgelaufen ist.

Sie sollten ein Bedürfnis äußern: "Ich brauche etwas zu trinken zum Mittagessen", und dann werden wir dafür sorgen, dass Sie etwas bekommen, wenn Sie sich zum Essen hinsetzen.

Answer 4

Dependency Injection ist eine mögliche Lösung für das, was man allgemein als "Dependency Obfuscation"-Anforderung bezeichnen könnte. Dependency Obfuscation ist eine Methode, um das "Offensichtliche" aus dem Prozess der Bereitstellung einer Abhängigkeit für eine Klasse, die diese benötigt, herauszunehmen und somit die Bereitstellung dieser Abhängigkeit für diese Klasse in gewisser Weise zu verschleiern. Dies ist nicht unbedingt eine schlechte Sache. Durch die Verschleierung der Art und Weise, wie eine Abhängigkeit für eine Klasse bereitgestellt wird, ist etwas außerhalb der Klasse für die Erstellung der Abhängigkeit verantwortlich, was bedeutet, dass in verschiedenen Szenarien eine andere Implementierung der Abhängigkeit für die Klasse bereitgestellt werden kann, ohne dass Änderungen an der Klasse vorgenommen werden müssen. Dies eignet sich hervorragend für den Wechsel zwischen Produktions- und Testmodus (z. B. bei Verwendung einer "Mock"-Dienstabhängigkeit).

Das Schlimme daran ist, dass einige Leute davon ausgehen, dass man ein spezielles Framework braucht, um Abhängigkeiten zu verschleiern, und dass man irgendwie ein "schlechterer" Programmierer ist, wenn man sich dafür entscheidet, kein bestimmtes Framework zu verwenden. Ein weiterer, äußerst beunruhigender Mythos, der von vielen geglaubt wird, ist, dass Dependency Injection die einzige Möglichkeit ist, Abhängigkeiten zu verschleiern. Dies ist nachweislich und historisch gesehen zu 100 % falsch, aber Sie werden Schwierigkeiten haben, einige Leute davon zu überzeugen, dass es Alternativen zur Dependency Injection für Ihre Anforderungen an die Verschleierung von Abhängigkeiten gibt.

Programmierer wissen seit Jahren, dass Abhängigkeiten verschleiert werden müssen, und viele alternative Lösungen haben sich sowohl vor als auch nach der Entwicklung der Dependency Injection entwickelt. Es gibt Factory-Muster, aber auch viele Optionen mit ThreadLocal, bei denen keine Injektion in eine bestimmte Instanz erforderlich ist - die Abhängigkeit wird effektiv in den Thread injiziert, was den Vorteil hat, dass das Objekt (über komfortable statische Getter-Methoden) für jede Klasse, die es benötigt, ohne Anmerkungen zu den Klassen, die es benötigen, hinzuzufügen und komplizierte XML-"Kleber" einzurichten, um es zu ermöglichen. Wenn Ihre Abhängigkeiten für die Persistenz erforderlich sind (JPA/JDO oder was auch immer), können Sie eine "tranaparente Persistenz" viel einfacher und mit Domänenmodell- und Geschäftsmodellklassen erreichen, die nur aus POJOs bestehen (d.h. keine frameworkspezifischen/eingesperrten Annotationen).

Answer 5

Aus Buch Apress.Spring.Persistenz.mit.Hibernate.Okt.2010

Der Zweck von Dependency Injection ist die Entkopplung der Arbeit der externen Softwarekomponenten von der Geschäftslogik Ihrer Anwendung zu entkoppeln. Ohne Dependency Injection können die Details, wie eine Komponente Komponente auf benötigte Dienste zugreift, mit dem Code der Komponente durcheinander Code. Dies erhöht nicht nur die Fehleranfälligkeit, sondern fügt auch Code und vergrößert die Komplexität der Wartung; es koppelt Komponenten Komponenten enger miteinander verbunden, was die Änderung von Abhängigkeiten beim Refactoring oder Testen.