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

Was ist Dependency Injection (DI)?

Wie andere gesagt haben, Dependency Injection(DI) die Verantwortung für die direkte Erstellung und Verwaltung der Lebensdauer anderer Objektinstanzen, von denen unsere Klasse von Interesse (Verbraucherklasse) abhängt, abnimmt (in der UML-Sinn ). Diese Instanzen werden stattdessen an unsere Verbraucherklasse übergeben, normalerweise als Konstruktorparameter oder über Eigenschaftssetzer (die Verwaltung der Instanzierung des Abhängigkeitsobjekts und die Übergabe an die Verbraucherklasse wird normalerweise von einer Inversion der Kontrolle (IoC) Container, aber das ist ein anderes Thema).

DI, DIP und SOLID

Speziell im Paradigma von Robert C. Martins SOLID-Grundsätze für objektorientiertes Design , DI ist eine der möglichen Implementierungen des Prinzip der Umkehrung von Abhängigkeiten (DIP) . Die DIP ist die D der SOLID Mantra - Andere DIP-Implementierungen umfassen die Muster Service Locator und Plugin.

Ziel des DIP ist es, enge, konkrete Abhängigkeiten zwischen Klassen zu entkoppeln und stattdessen die Kopplung durch eine Abstraktion zu lockern, die über eine interface , abstract class o pure virtual class je nach der verwendeten Sprache und Vorgehensweise.

Ohne das DIP ist unser Code (ich nenne ihn "konsumierende Klasse") direkt an eine konkrete Abhängigkeit gekoppelt und ist außerdem oft mit der Verantwortung belastet, zu wissen, wie man eine Instanz dieser Abhängigkeit erhält und verwaltet, d.h. konzeptionell:

"I need to create/use a Foo and invoke method `GetBar()`"

In der Erwägung, dass nach der Anwendung des DIP die Anforderung gelockert wird und die Sorge um die Erlangung und Verwaltung der Lebensdauer des Foo Abhängigkeit wurde entfernt:

"I need to invoke something which offers `GetBar()`"

Warum DIP (und DI) verwenden?

Die Entkopplung von Abhängigkeiten zwischen Klassen auf diese Weise ermöglicht einfache Substitution dieser Abhängigkeitsklassen mit anderen Implementierungen, die ebenfalls die Voraussetzungen der Abstraktion erfüllen (z.B. kann die Abhängigkeit mit einer anderen Implementierung der gleichen Schnittstelle getauscht werden). Außerdem können, wie bereits erwähnt, möglicherweise die Der häufigste Grund für die Entkopplung von Klassen über das DIP ist, dass eine konsumierende Klasse isoliert getestet werden kann, da dieselben Abhängigkeiten nun stubbed und/oder mocked werden können.

Eine Folge von DI ist, dass die Verwaltung der Lebensdauer von Instanzen von Abhängigkeitsobjekten nicht mehr von einer konsumierenden Klasse kontrolliert wird, da das Abhängigkeitsobjekt nun an die konsumierende Klasse übergeben wird (über Konstruktor- oder Setter-Injektion).

Dies kann auf unterschiedliche Weise betrachtet werden:

• Wenn die Lebenszeitkontrolle über die Abhängigkeiten durch die konsumierende Klasse beibehalten werden muss, kann die Kontrolle wiederhergestellt werden, indem eine (abstrakte) Fabrik zur Erzeugung der Instanzen der Abhängigkeitsklasse in die Konsumentenklasse injiziert wird. Der Konsument kann die Instanzen über eine Create in der Fabrik, und entsorgen Sie diese Instanzen, sobald sie fertig sind.
• Oder die Kontrolle über die Lebensdauer von Abhängigkeitsinstanzen kann an einen IoC-Container abgegeben werden (mehr dazu weiter unten).

Wann sollte man DI verwenden?

• Wenn es wahrscheinlich notwendig ist, eine Abhängigkeit durch eine gleichwertige Implementierung zu ersetzen,
• Immer dann, wenn Sie die Methoden einer Klasse isoliert von ihren Abhängigkeiten testen müssen,
• Wenn die Ungewissheit über die Lebensdauer einer Abhängigkeit ein Experiment rechtfertigt (z. B. Hey, MyDepClass ist thread-sicher - was, wenn wir es zu einem Singleton machen und dieselbe Instanz in alle Verbraucher injizieren?)

Ejemplo

Hier ist eine einfache C#-Implementierung. Gegeben die unten Consuming Klasse:

public class MyLogger
{
   public void LogRecord(string somethingToLog)
   {
      Console.WriteLine("{0:HH:mm:ss} - {1}", DateTime.Now, somethingToLog);
   }
}

Obwohl es scheinbar harmlos ist, hat es zwei static Abhängigkeiten von zwei anderen Klassen, System.DateTime y System.Console die nicht nur die Optionen für die Protokollierung einschränken (die Protokollierung auf der Konsole ist wertlos, wenn niemand zuschaut), sondern, was noch schlimmer ist, angesichts der Abhängigkeit von einer nicht-deterministischen Systemuhr schwer automatisch zu testen sind.

Wir können jedoch anwenden DIP zu dieser Klasse, indem die Zeitstempelung als Abhängigkeit abstrahiert wird und die MyLogger nur auf eine einfache Schnittstelle:

public interface IClock
{
    DateTime Now { get; }
}

Wir können auch die Abhängigkeit von Console zu einer Abstraktion, wie zum Beispiel einer TextWriter . Dependency Injection wird typischerweise implementiert als entweder constructor Injektion (Übergabe einer Abstraktion an eine Abhängigkeit als Parameter an den Konstruktor einer konsumierenden Klasse) oder Setter Injection (Übergabe der Abhängigkeit über eine setXyz() Setter oder eine .Net-Eigenschaft mit {set;} definiert). Constructor Injection ist zu bevorzugen, da dies garantiert, dass sich die Klasse nach der Konstruktion in einem korrekten Zustand befindet, und es erlaubt, die internen Abhängigkeitsfelder als readonly (C#) oder final (Java). Wenn wir also die Konstruktorinjektion auf das obige Beispiel anwenden, ergibt sich folgendes Bild:

public class MyLogger : ILogger // Others will depend on our logger.
{
    private readonly TextWriter _output;
    private readonly IClock _clock;

    // Dependencies are injected through the constructor
    public MyLogger(TextWriter stream, IClock clock)
    {
        _output = stream;
        _clock = clock;
    }

    public void LogRecord(string somethingToLog)
    {
        // We can now use our dependencies through the abstraction 
        // and without knowledge of the lifespans of the dependencies
        _output.Write("{0:yyyy-MM-dd HH:mm:ss} - {1}", _clock.Now, somethingToLog);
    }
}

(Eine konkrete Clock zur Verfügung gestellt werden muss, die natürlich auch auf DateTime.Now und die beiden Abhängigkeiten müssen von einem IoC-Container über Konstruktorinjektion bereitgestellt werden)

Ein automatisierter Unit Test kann erstellt werden, der definitiv beweist, dass unser Logger korrekt arbeitet, da wir nun die Kontrolle über die Abhängigkeiten haben - die Zeit, und wir können die geschriebene Ausgabe ausspionieren:

[Test]
public void LoggingMustRecordAllInformationAndStampTheTime()
{
    // Arrange
    var mockClock = new Mock<IClock>();
    mockClock.Setup(c => c.Now).Returns(new DateTime(2015, 4, 11, 12, 31, 45));
    var fakeConsole = new StringWriter();

    // Act
    new MyLogger(fakeConsole, mockClock.Object)
        .LogRecord("Foo");

    // Assert
    Assert.AreEqual("2015-04-11 12:31:45 - Foo", fakeConsole.ToString());
}

Nächste Schritte

Dependency Injection ist immer mit einer Inversion of Control Container (IoC) , um die konkreten Abhängigkeitsinstanzen zu injizieren (bereitzustellen) und um die Lebenszeitinstanzen zu verwalten. Während des Konfigurations-/Bootstrapping-Prozesses, IoC Container ermöglichen es, Folgendes zu definieren:

• Abbildung zwischen jeder Abstraktion und der konfigurierten konkreten Implementierung (z. B. "jedes Mal, wenn ein Verbraucher einen Antrag auf IBar Rückgabe a ConcreteBar Instanz" )
• Es können Richtlinien für die Verwaltung der Lebensdauer jeder Abhängigkeit festgelegt werden, z. B. für die Erstellung eines neuen Objekts für jede Verbraucherinstanz, für die gemeinsame Nutzung einer Singleton-Abhängigkeitsinstanz durch alle Verbraucher, für die gemeinsame Nutzung derselben Abhängigkeitsinstanz nur durch denselben Thread, usw.
• In .Net sind IoC-Container mit Protokollen wie IDisposable und wird die Verantwortung übernehmen für Disposing Abhängigkeiten im Einklang mit dem konfigurierten Lebensdauermanagement.

Sobald IoC-Container konfiguriert / gebootstrappt wurden, arbeiten sie in der Regel nahtlos im Hintergrund, so dass sich der Programmierer auf den eigentlichen Code konzentrieren kann, anstatt sich um Abhängigkeiten zu kümmern.

Der Schlüssel zu DI-freundlichem Code liegt darin, statische Kopplung von Klassen zu vermeiden und new() nicht für die Erstellung von Abhängigkeiten zu verwenden

Wie im obigen Beispiel erfordert die Entkopplung von Abhängigkeiten einen gewissen Entwurfsaufwand, und für den Entwickler ist ein Paradigmenwechsel erforderlich, um mit der Gewohnheit zu brechen new Abhängigkeiten zu vermeiden und stattdessen dem Container zu vertrauen, der die Abhängigkeiten verwaltet.

Aber die Vorteile sind vielfältig, vor allem die Möglichkeit, die Klasse, die Sie interessiert, gründlich zu testen.

Hinweis : Die Erstellung / Kartierung / Projektion (via new ..() ) von POCO / POJO / Serialisierungs-DTOs / Entitätsgraphen / anonymen JSON-Projektionen u. a. - d. h. "Nur-Daten"-Klassen oder -Datensätze - verwendet oder von Methoden zurückgegeben werden no als Abhängigkeiten (im Sinne der UML) betrachtet und unterliegen nicht der DI. Verwendung von new diese zu projizieren, ist genau richtig.

Answer 2

Alle oben genannten Antworten sind gut, mein Ziel ist es, das Konzept auf einfache Weise zu erklären, so dass jeder, der keine Programmierkenntnisse hat, das Konzept auch verstehen kann

Dependency Injection ist eines der Entwurfsmuster, die uns helfen, komplexe Systeme auf einfachere Weise zu erstellen.

Wir können dieses Muster in unserem täglichen Leben auf vielfältige Weise anwenden. Einige der Beispiele sind Tonbandgerät, VCD, CD-Laufwerk usw.

Das obige Bild ist ein Bild des tragbaren Tonbandgeräts Reel-to-reel, Mitte des 20. Jahrhunderts. Quelle .

Der Hauptzweck eines Tonbandgeräts ist die Aufnahme oder Wiedergabe von Ton.

Bei der Entwicklung eines Systems wird eine Spule zur Aufnahme oder Wiedergabe von Ton oder Musik benötigt. Für die Gestaltung dieses Systems gibt es zwei Möglichkeiten

1. wir können die Spule in die Maschine einbauen
2. Wir können einen Haken für die Rolle bereitstellen, an dem sie angebracht werden kann.

Wenn wir die erste verwenden, müssen wir die Maschine öffnen, um die Spule zu wechseln. Wenn wir uns für die zweite Variante entscheiden, d.h. einen Haken für die Spule anbringen, haben wir den zusätzlichen Vorteil, dass wir jede beliebige Musik abspielen können, indem wir die Spule wechseln und die Funktion auf das Abspielen des Inhalts der Spule beschränken.

Ähnlich wie bei der Dependency Injection werden die Abhängigkeiten externalisiert, um sich nur auf die spezifische Funktionalität der Komponente zu konzentrieren, so dass unabhängige Komponenten zu einem komplexen System zusammengefügt werden können.

Die wichtigsten Vorteile, die wir durch die Verwendung von Dependency Injection erreicht haben.

• Hohe Kohäsion und lose Kopplung.
• Externalisierung der Abhängigkeit und ausschließlicher Blick auf die Verantwortung.
• Dinge als Komponenten herstellen und zu einem großen System mit hohen Fähigkeiten kombinieren.
• Es hilft bei der Entwicklung qualitativ hochwertiger Komponenten, da sie unabhängig entwickelt und ordnungsgemäß getestet werden.
• Es ist hilfreich, das Bauteil durch ein anderes zu ersetzen, wenn es ausfällt.

Heutzutage bilden diese Konzepte die Grundlage für bekannte Frameworks in der Welt der Programmierung. Spring, Angular usw. sind die bekannten Software-Frameworks, die auf diesem Konzept basieren

Dependency Injection ist ein Muster, das verwendet wird, um Instanzen von Objekten zu erstellen, auf die andere Objekte angewiesen sind, ohne zum Zeitpunkt der Kompilierung zu wissen, welche Klasse verwendet wird, um diese Funktionalität bereitzustellen, oder einfach die Art der Injektion von Eigenschaften in ein Objekt wird als Dependency Injection bezeichnet.

Beispiel für Dependency Injection

Bisher haben wir Code wie diesen geschrieben

Public MyClass{
 DependentClass dependentObject
 /*
  At somewhere in our code we need to instantiate 
  the object with new operator  inorder to use it or perform some method.
  */ 
  dependentObject= new DependentClass();
  dependentObject.someMethod();
}

Mit Dependency Injection wird der Dependency Injector die Instanziierung für uns übernehmen

Public MyClass{
 /* Dependency injector will instantiate object*/
 DependentClass dependentObject

 /*
  At somewhere in our code we perform some method. 
  The process of  instantiation will be handled by the dependency injector
 */ 

  dependentObject.someMethod();
}

Sie können auch lesen

Unterschied zwischen Inversion of Control und Dependency Injection

Answer 3

Der Sinn von Dependency Injection (DI) besteht darin, den Quellcode der Anwendung sauber y stabil :

• sauber Code für die Initialisierung von Abhängigkeiten
• stabil unabhängig von der verwendeten Abhängigkeit

Praktisch jedes Entwurfsmuster trennt Bedenken, damit zukünftige Änderungen nur minimale Dateien betreffen.

Der spezifische Bereich der DI ist die Delegation der Konfiguration und Initialisierung von Abhängigkeiten.

Beispiel: DI mit Shell-Skript

Wenn Sie gelegentlich außerhalb von Java arbeiten, erinnern Sie sich daran, wie source wird häufig in vielen Skriptsprachen verwendet (Shell, Tcl usw. oder auch import in Python für diesen Zweck missbraucht).

Betrachten Sie einfach dependent.sh Drehbuch:

#!/bin/sh
# Dependent
touch         "one.txt" "two.txt"
archive_files "one.txt" "two.txt"

Das Skript ist abhängig: Es wird nicht von alleine erfolgreich ausgeführt ( archive_files ist nicht definiert).

Sie definieren archive_files en archive_files_zip.sh Implementierungsskript (mit zip in diesem Fall):

#!/bin/sh
# Dependency
function archive_files {
    zip files.zip "$@"
}

Anstelle von source -Implementierungsskript direkt in das abhängige Skript einzufügen, verwenden Sie ein injector.sh "Container", der beide "Komponenten" umschließt:

#!/bin/sh 
# Injector
source ./archive_files_zip.sh
source ./dependent.sh

El archive_files Abhängigkeiten wurde gerade eingespritzt in abhängig Drehbuch.

Sie könnten eine Abhängigkeit injiziert haben, die Folgendes implementiert archive_files mit tar o xz .

Beispiel: Entfernen von DI

Wenn dependent.sh Skript Abhängigkeiten direkt verwendet, würde der Ansatz heißen Suche nach Abhängigkeiten (was im Gegensatz zu Dependency Injection ):

#!/bin/sh
# Dependent

# dependency look-up
source ./archive_files_zip.sh

touch         "one.txt" "two.txt"
archive_files "one.txt" "two.txt"

Das Problem ist nun, dass die abhängige "Komponente" die Initialisierung selbst durchführen muss.

Der Quellcode der "Komponente" ist weder sauber noch stabil denn jede Änderung in der Initialisierung der Abhängigkeiten erfordert auch eine neue Freigabe der Quellcodedatei der "Komponenten".

Letzte Worte

DI wird nicht so stark betont und popularisiert wie in Java-Frameworks.

Aber es ist ein allgemeiner Ansatz zur Aufteilung von Anliegen:

• Anmeldung Entwicklung ( einzeln Lebenszyklus der Veröffentlichung des Quellcodes)
• Anmeldung Bereitstellung ( mehrere Zielumgebungen mit unabhängigen Lebenszyklen)

Verwendung der Konfiguration nur mit Suche nach Abhängigkeiten ist nicht hilfreich, da sich die Anzahl der Konfigurationsparameter pro Abhängigkeit (z. B. neuer Authentifizierungstyp) sowie die Anzahl der unterstützten Arten von Abhängigkeiten (z. B. neuer Datenbanktyp) ändern kann.

Answer 4

Beispiel, wir haben 2 Klassen Client y Service . Client wird verwendet Service

public class Service {
    public void doSomeThingInService() {
        // ...
    }
}

Ohne Dependency Injection

Weg 1)

public class Client {
    public void doSomeThingInClient() {
        Service service = new Service();
        service.doSomeThingInService();
    }
}

Weg 2)

public class Client {
    Service service = new Service();
    public void doSomeThingInClient() {
        service.doSomeThingInService();
    }
}

Weg 3)

public class Client {
    Service service;
    public Client() {
        service = new Service();
    }
    public void doSomeThingInClient() {
        service.doSomeThingInService();
    }
}

1) 2) 3) Verwendung

Client client = new Client();
client.doSomeThingInService();

Vorteile

• Einfach

Benachteiligungen

• Hart im Nehmen Client クラス
• Wenn wir uns ändern Service Konstruktor, müssen wir den Code an allen Stellen ändern, die Service Objekt

Verwenden Sie Dependency Injection

Weg 1) Injektion des Konstruktors

public class Client {
    Service service;

    Client(Service service) {
        this.service = service;
    }

    // Example Client has 2 dependency 
    // Client(Service service, IDatabas database) {
    //    this.service = service;
    //    this.database = database;
    // }

    public void doSomeThingInClient() {
        service.doSomeThingInService();
    }
}

Verwendung von

Client client = new Client(new Service());
// Client client = new Client(new Service(), new SqliteDatabase());
client.doSomeThingInClient();

Weg 2) Setter-Injektion

public class Client {
    Service service;

    public void setService(Service service) {
        this.service = service;
    }

    public void doSomeThingInClient() {
        service.doSomeThingInService();
    }
}

Verwendung von

Client client = new Client();
client.setService(new Service());
client.doSomeThingInClient();

Weg 3) Injektion der Schnittstelle

Siehe https://en.wikipedia.org/wiki/Dependency_injection

\===

Nun, dieser Code folgt bereits Dependency Injection und es ist einfacher für den Test Client Klasse.
Wir verwenden jedoch weiterhin new Service() viele Male und es ist nicht gut, wenn Veränderungen Service Konstrukteur. Um dies zu verhindern, können wir einen DI-Injektor wie
1) Einfaches Handbuch Injector

public class Injector {
    public static Service provideService(){
        return new Service();
    }

    public static IDatabase provideDatatBase(){
        return new SqliteDatabase();
    }
    public static ObjectA provideObjectA(){
        return new ObjectA(provideService(...));
    }
}

Verwendung von

Service service = Injector.provideService();

2) Bibliothek benutzen: Für Android Dolch2

Vorteile

• Erleichterung der Prüfung
• Wenn Sie die Service müssen Sie sie nur in der Klasse Injector ändern
• Wenn Sie verwenden Constructor Injection Wenn Sie sich den Konstruktor von Client werden Sie sehen, wie viele Abhängigkeiten von Client クラス

Benachteiligungen

• Wenn Sie verwenden Constructor Injection die Service Objekt wird erstellt, wenn Client erstellt, manchmal verwenden wir die Funktion in Client Klasse ohne Verwendung Service so erstellt Service ist umsonst

Definition von Dependency Injection

https://en.wikipedia.org/wiki/Dependency_injection

Eine Abhängigkeit ist ein Objekt, das verwendet werden kann ( Service )
Eine Injektion ist die Übergabe einer Abhängigkeit ( Service ) auf ein abhängiges Objekt ( Client ), die es verwenden würden

Answer 5

Was ist Dependency Injection?

Dependency Injection (DI) bedeutet, dass die Objekte, die voneinander abhängig sind, entkoppelt werden. Sagen wir, Objekt A ist abhängig von Objekt B. Die Idee ist also, diese Objekte voneinander zu entkoppeln. Wir brauchen das Objekt nicht hart zu kodieren, indem wir das Schlüsselwort new verwenden, sondern wir teilen die Abhängigkeiten zu den Objekten zur Laufzeit trotz der Kompilierungszeit. Wenn wir über

Wie Dependency Injection in Spring funktioniert:

Wir müssen das Objekt nicht mit dem Schlüsselwort new hart codieren, sondern die Bean-Abhängigkeit in der Konfigurationsdatei definieren. Der Spring-Container ist für das Einbinden aller Beans verantwortlich.

Umkehrung der Kontrolle (IOC)

IOC ist ein allgemeines Konzept, das auf viele verschiedene Arten ausgedrückt werden kann, und Dependency Injection ist ein konkretes Beispiel für IOC.

Zwei Arten von Dependency Injection:

1. Konstruktor Injektion
2. Setzer Injektion

1. Konstruktorbasierte Injektion von Abhängigkeiten:

Konstruktorbasierte DI wird erreicht, wenn der Container einen Klassenkonstruktor mit einer Reihe von Argumenten aufruft, die jeweils eine Abhängigkeit von einer anderen Klasse darstellen.

public class Triangle {

private String type;

public String getType(){
    return type;
 }

public Triangle(String type){   //constructor injection
    this.type=type;
 }
}
<bean id=triangle" class ="com.test.dependencyInjection.Triangle">
        <constructor-arg value="20"/>
  </bean>

2. Setter-basierte Injektion von Abhängigkeiten:

Setter-basierte DI wird erreicht, indem der Container Setter-Methoden für Ihre Beans aufruft, nachdem er einen Konstruktor ohne Argumente oder eine statische Fabrikmethode ohne Argumente aufgerufen hat, um Ihre Bean zu instanziieren.

public class Triangle{

 private String type;

 public String getType(){
    return type;
  }
 public void setType(String type){          //setter injection
    this.type = type;
  }
 }

<!-- setter injection -->
 <bean id="triangle" class="com.test.dependencyInjection.Triangle">
        <property name="type" value="equivialteral"/>

HINWEIS: Es ist eine gute Faustregel, Konstruktorargumente für obligatorische Abhängigkeiten und Setter für optionale Abhängigkeiten zu verwenden. Beachten Sie, dass die @Required-Annotation auf einem Setter verwendet werden kann, um Setter als erforderliche Abhängigkeiten zu kennzeichnen.