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

Ich würde eine etwas andere, kurze und präzise Definition von Dependency Injection vorschlagen, die sich auf das primäre Ziel und nicht auf die technischen Mittel konzentriert (in Anlehnung an aquí ):

Dependency Injection ist der Prozess der Erstellung der statischen, zustandslosen Graphen von Dienstobjekten, bei dem jeder Dienst durch seine Abhängigkeiten parametrisiert ist.

Die Objekte, die wir in unseren Anwendungen erstellen (unabhängig davon, ob wir Java, C# oder eine andere objektorientierte Sprache verwenden), fallen in der Regel in eine von zwei Kategorien: zustandslose, statische und globale "Dienstobjekte" (Module) und zustandsabhängige, dynamische und lokale "Datenobjekte".

Der Modulgraph - der Graph der Dienstobjekte - wird normalerweise beim Start der Anwendung erstellt. Dies kann mithilfe eines Containers wie Spring geschehen, aber auch manuell durch Übergabe von Parametern an Objektkonstruktoren. Beide Wege haben ihre Vor- und Nachteile, aber ein Framework ist definitiv nicht notwendig, um DI in Ihrer Anwendung zu verwenden.

Eine Anforderung ist, dass die Dienste durch ihre Abhängigkeiten parametrisiert werden müssen. Was dies genau bedeutet, hängt von der Sprache und dem Ansatz ab, der in einem bestimmten System verfolgt wird. In der Regel geschieht dies in Form von Konstruktorparametern, aber auch die Verwendung von Settern ist eine Option. Dies bedeutet auch, dass die Abhängigkeiten eines Dienstes (beim Aufruf einer Dienstmethode) vor den Benutzern des Dienstes verborgen werden.

Wann ist sie zu verwenden? Ich würde sagen, immer dann, wenn die Anwendung groß genug ist, dass die Kapselung der Logik in separaten Modulen mit einem Abhängigkeitsdiagramm zwischen den Modulen einen Gewinn an Lesbarkeit und Explorierbarkeit des Codes bringt.

Answer 2

Aus Christoffer Noring, Pablo Deeleman's Buch "Learning Angular - Second Edition":

"Als unser Anwendungen wachsen und sich entwickeln, jeder von uns Code-Entitäten erfordert intern Instanzen von anderen Objekten die besser bekannt sind als Abhängigkeiten in der Welt der Softwareentwicklung. Die Aktion der Verabschiedung solcher Abhängigkeiten an den abhängigen Kunden ist bekannt als Einspritzung und umfasst auch die Beteiligung einer weiteren Code-Einheit, der Einspritzventil . Die Einspritzventil wird die Verantwortung übernehmen für Instanziierung y bootstrapping die erforderlichen Abhängigkeiten Sie sind also von dem Moment an einsatzbereit, in dem sie dem Kunden erfolgreich injiziert wurden. Dies ist sehr wichtig, da der Kunde nichts darüber weiß, wie man instanziieren seine eigene Abhängigkeiten und ist sich nur der Schnittstelle die sie umsetzen, um sie zu nutzen".

Von: Anton Moiseev. Buch "Angular Development with Typescript, Second Edition.":

"Kurz gesagt, DI hilft Ihnen beim Schreiben von Code in einer lose gekoppelt Weg und macht Ihre Code plus prüfbar y wiederverwendbar ."

Answer 3

Mit einfachen Worten: Dependency Injection (DI) ist der Weg zur Beseitigung von Abhängigkeiten oder enger Kopplung zwischen verschiedenen Objekten. Dependency Injection gibt jedem Objekt ein kohärentes Verhalten.

DI ist die Umsetzung des IOC-Prinzips von Spring, das besagt "Rufen Sie uns nicht an, wir rufen Sie an". Bei der Verwendung von Dependency Injection muss der Programmierer kein Objekt mit dem Schlüsselwort new erstellen.

Die Objekte werden einmal in den Spring-Container geladen und dann bei Bedarf wiederverwendet, indem diese Objekte mit der Methode getBean(String beanName) aus dem Spring-Container geholt werden.

Answer 4

Dependency Injection (DI) ist Teil der Dependency Inversion Principle (DIP) Praxis, die auch als Inversion of Control (IoC) bezeichnet wird. Im Grunde genommen müssen Sie DIP durchführen, weil Sie Ihren Code modularer und unit-testbar machen wollen, anstatt nur ein monolithisches System zu haben. Man beginnt also damit, Teile des Codes zu identifizieren, die von der Klasse getrennt und abstrahiert werden können. Nun muss die Implementierung der Abstraktion von außerhalb der Klasse injiziert werden. Normalerweise kann dies über einen Konstruktor geschehen. Man erstellt also einen Konstruktor, der die Abstraktion als Parameter akzeptiert, und das nennt man Dependency Injection (via Konstruktor). Weitere Erklärungen zu DIP, DI und IoC-Container finden Sie unter Hier

Answer 5

Dependency Injection (DI) ist eine von Design Patterns, die das grundlegende Merkmal von OOP nutzt - die Beziehung eines Objekts zu einem anderen Objekt. Während Vererbung ein Objekt erbt, um ein komplexeres und spezifischeres anderes Objekt zu tun, erstellt Beziehung oder Assoziation einfach einen Zeiger auf ein anderes Objekt von einem Objekt mit Attribut. Die Stärke von DI liegt in der Kombination mit anderen Merkmalen von OOP wie Schnittstellen und dem Verstecken von Code. Angenommen, wir haben einen Kunden (Abonnenten) in der Bibliothek, der der Einfachheit halber nur ein Buch ausleihen kann.

Schnittstelle des Buches:

package com.deepam.hidden;

public interface BookInterface {

public BookInterface setHeight(int height);
public BookInterface setPages(int pages);   
public int getHeight();
public int getPages();  

public String toString();
}

Dann gibt es viele Arten von Büchern; eine davon ist die Belletristik:

package com.deepam.hidden;

public class FictionBook implements BookInterface {
int height = 0; // height in cm
int pages = 0; // number of pages

/** constructor */
public FictionBook() {
    // TODO Auto-generated constructor stub
}

@Override
public FictionBook setHeight(int height) {
  this.height = height;
  return this;
}

@Override
public FictionBook setPages(int pages) {
  this.pages = pages;
  return this;      
}

@Override
public int getHeight() {
    // TODO Auto-generated method stub
    return height;
}

@Override
public int getPages() {
    // TODO Auto-generated method stub
    return pages;
}

@Override
public String toString(){
    return ("height: " + height + ", " + "pages: " + pages);
}
}

Jetzt können Abonnenten eine Verbindung zu dem Buch herstellen:

package com.deepam.hidden;

import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;

public class Subscriber {
BookInterface book;

/** constructor*/
public Subscriber() {
    // TODO Auto-generated constructor stub
}

// injection I
public void setBook(BookInterface book) {
    this.book = book;
}

// injection II
public BookInterface setBook(String bookName) {
    try {
        Class<?> cl = Class.forName(bookName);
        Constructor<?> constructor = cl.getConstructor(); // use it for parameters in constructor
        BookInterface book = (BookInterface) constructor.newInstance();
        //book = (BookInterface) Class.forName(bookName).newInstance();
    } catch (InstantiationException e) {
        e.printStackTrace();
    } catch (IllegalAccessException e) {
        e.printStackTrace();
    } catch (ClassNotFoundException e) {
        e.printStackTrace();
    } catch (NoSuchMethodException e) {
        e.printStackTrace();
    } catch (SecurityException e) {
        e.printStackTrace();
    } catch (IllegalArgumentException e) {
        e.printStackTrace();
    } catch (InvocationTargetException e) {
        e.printStackTrace();
    }
    return book;
}

public BookInterface getBook() {
  return book;
}

public static void main(String[] args) {

}

}

Alle drei Klassen können für ihre eigene Implementierung ausgeblendet werden. Jetzt können wir diesen Code für DI verwenden:

package com.deepam.implement;

import com.deepam.hidden.Subscriber;
import com.deepam.hidden.FictionBook;

public class CallHiddenImplBook {

public CallHiddenImplBook() {
    // TODO Auto-generated constructor stub
}

public void doIt() {
    Subscriber ab = new Subscriber();

    // injection I
    FictionBook bookI = new FictionBook();
    bookI.setHeight(30); // cm
    bookI.setPages(250);
    ab.setBook(bookI); // inject
    System.out.println("injection I " + ab.getBook().toString());

    // injection II
    FictionBook bookII = ((FictionBook) ab.setBook("com.deepam.hidden.FictionBook")).setHeight(5).setPages(108); // inject and set
    System.out.println("injection II " + ab.getBook().toString());      
}

public static void main(String[] args) {
    CallHiddenImplBook kh = new CallHiddenImplBook();
    kh.doIt();
}
}

Es gibt viele verschiedene Möglichkeiten, die Dependency Injection zu nutzen. Es ist möglich, es mit Singleton usw. zu kombinieren, aber im Grunde ist es nur eine Assoziation, die durch das Erstellen von Attributen eines Objekttyps innerhalb eines anderen Objekts realisiert wird. Die Nützlichkeit liegt einzig und allein in der Eigenschaft, dass der Code, den wir immer wieder schreiben sollen, immer schon für uns vorbereitet und erledigt ist. Deshalb ist DI so eng mit Inversion of Control (IoC) verknüpft, was bedeutet, dass unser Programm die Kontrolle an ein anderes laufendes Modul weitergibt, das Injektionen von Beans in unseren Code vornimmt. (Jedes Objekt, das injiziert werden kann, kann signiert oder als Bean betrachtet werden.) In Spring wird dies zum Beispiel durch das Erstellen und Initialisieren von Anwendungskontext Container, der diese Arbeit für uns erledigt. Wir erstellen in unserem Code einfach den Context und rufen die Initialisierung der Beans auf. In diesem Moment ist die Injektion automatisch erfolgt.