Inversion der Kontrolle vs. Dependency Injection

Question

Nach Angaben der Beitrag von Martin Fowler Die Umkehrung der Kontrolle ist das Prinzip, bei dem der Kontrollfluss eines Programms umgekehrt wird: Anstatt dass der Programmierer den Fluss eines Programms kontrolliert, übernehmen die externen Quellen (Rahmen, Dienste, andere Komponenten) die Kontrolle darüber. Es ist, als ob wir etwas in etwas anderes einstecken. Er erwähnte ein Beispiel über EJB 2.0:

Zum Beispiel die Session Bean Schnittstelle definiert ejbRemove, ejbPassivate (Speicherung im Sekundärspeicher) und ejbActivate (Wiederherstellung aus passiven Zustand). Sie haben keine Kontrolle darüber, wann diese Methoden aufgerufen werden, sondern nur was sie tun. Der Container ruft uns auf, wir rufen ihn nicht auf.

Dies führt zu dem Unterschied zwischen Framework und Bibliothek:

Die Umkehrung der Kontrolle ist ein wichtiger Bestandteil der was ein Framework von einer Bibliothek unterscheidet. Bibliothek unterscheidet. Eine Bibliothek ist im Wesentlichen eine Satz von Funktionen, die Sie aufrufen können, Heutzutage üblicherweise organisiert in Klassen. Jeder Aufruf erledigt etwas Arbeit und gibt die Kontrolle an den Client zurück.

Ich denke, dass die Sichtweise, dass DI IOC ist, bedeutet, dass die Abhängigkeit eines Objekts umgekehrt ist: anstatt dass es seine eigenen Abhängigkeiten, seinen Lebenszyklus... kontrolliert, macht das etwas anderes für Sie. Aber, wie Sie mir über DI mit den Händen gesagt haben, ist DI nicht unbedingt IOC. Wir können immer noch DI und kein IOC haben.

In diesem Papier (von pococapsule, einem anderen IOC-Framework für C/C++) wird jedoch vorgeschlagen, dass die IOC-Container und DI-Frameworks aufgrund von IOC und DI J2EE weit überlegen sind, da J2EE den Framework-Code in die Komponenten einmischt und sie somit nicht zu Plain Old Java/C++ Object (POJO/POCO) macht.

Inversion der Kontrolle Andere Container als das Dependency Injection Muster (Archiv-Link)

Weitere Lektüre, um zu verstehen, was das Problem mit dem alten komponentenbasierten Entwicklungsrahmen ist, was zu dem oben genannten zweiten Papier führt: Warum und was ist die Umkehrung der Kontrolle? (Archiv-Link)

Meine Frage : Was genau sind IOC und DI? Ich bin verwirrt. Ausgehend von pococapsule ist IOC etwas Bedeutsameres als nur die Umkehrung der Kontrolle zwischen Objekten oder Programmierern und Frameworks.

Answer 1

Die  Inversion-of-Control  (IoC)  Muster, geht es um die Bereitstellung  jede Art  von  callback  (der die Reaktion "implementiert" und/oder steuert), anstatt selbst direkt zu handeln (mit anderen Worten: Umkehrung und/oder Umleitung der Kontrolle an den externen Handler/Controller).

Anstatt beispielsweise die Anwendung die Implementierungen aufrufen zu lassen, die von einem Bibliothek (auch bekannt als Werkzeugsatz ), a Rahmenwerk ruft die von der Anwendung bereitgestellten Implementierungen auf.

Die  Dependency-Injection  (DI)  Muster ist eine spezifischere Version des IoC-Musters, bei dem Implementierungen über Konstruktoren/Setzer/Dienstnachschlagewerke an ein Objekt übergeben werden, von denen das Objekt "abhängig" ist, um sich korrekt zu verhalten.

Alle DI Umsetzung kann berücksichtigt werden IoC aber man sollte es nicht als IoC weil die Implementierung von Dependency-Injection schwieriger ist als Callback (werten Sie Ihr Produkt nicht ab, indem Sie stattdessen den allgemeinen Begriff "IoC" verwenden).

IoC ohne Verwendung von DI wäre z. B. das Template-Muster, da die Implementierung nur durch Sub-Classing geändert werden kann.

DI-Rahmenwerke sind für die Verwendung von DI konzipiert und können Schnittstellen (oder Annotationen in Java) definieren, um die Übergabe der Implementierungen zu erleichtern.

IoC-Container sind DI-Frameworks, die außerhalb der Programmiersprache arbeiten können. Bei einigen können Sie konfigurieren, welche Implementierungen in Metadaten-Dateien (z. B. XML) verwendet werden sollen, was weniger invasiv ist. Mit einigen kann man IoC durchführen, was normalerweise unmöglich wäre, wie z.B. das Einfügen einer Implementierung bei pointcuts .

Siehe auch dies Der Artikel von Martin Fowler .

Answer 2

Kurz gesagt, IoC ist ein viel weiter gefasster Begriff, der unter anderem DI

Der Begriff Inversion of Control (IoC) bezeichnete ursprünglich jede Art von Programmierstil, bei dem eine übergeordnete Rahmenwerk oder die Laufzeit den Programmablauf kontrolliert

Bevor DI einen Namen hatte, bezeichnete man Frameworks, die Abhängigkeiten verwalten, als Inversion of Control Containers zu bezeichnen, und bald driftete die Bedeutung von IoC allmählich in diese spezielle Bedeutung ab: Inversion of Control over Dependencies (Inversion der Kontrolle über Abhängigkeiten).

Umkehrung der Kontrolle (IoC) bedeutet, dass Objekte keine anderen Objekte erzeugen, auf die sie angewiesen sind, um ihre Arbeit zu erledigen. Stattdessen beziehen sie die Objekte, die sie benötigen, aus einer externen Quelle (z. B. einer XML-Konfigurationsdatei).

Injektion von Abhängigkeiten (DI) bedeutet, dass dies ohne Eingreifen des Objekts geschieht, normalerweise durch eine Rahmenkomponente, die Konstruktorparameter übergibt und Eigenschaften setzt.

Answer 3

Quelle

IoC ( I nversion o f C ontrol) :- Es ist ein allgemeiner Begriff und kann auf verschiedene Weise implementiert werden (Ereignisse, Delegierte usw.).

DI ( D ependenz I njection) :- DI ist ein Untertyp von IoC und wird implementiert durch Konstruktorinjektion, Setterinjektion oder Schnittstelleninjektion .

Spring unterstützt jedoch nur die beiden folgenden Typen:

• Setzer Injektion
  • Setter-basierte DI wird durch den Aufruf von Setter-Methoden auf den Beans des Benutzers realisiert, nachdem ein Konstruktor ohne Argumente oder eine statische Fabrikmethode ohne Argumente zur Instanziierung ihrer Beans aufgerufen wurde.
• Konstruktor Injektion
  • Konstruktorbasierte DI wird durch den Aufruf eines Konstruktors mit einer Reihe von Argumenten realisiert, von denen jedes einen Kollaborateur repräsentiert; auf diese Weise können wir überprüfen, dass die injizierten Beans nicht null sind und schnell fehlschlagen (beim Kompilieren und nicht zur Laufzeit), so dass wir beim Starten der Anwendung selbst Folgendes erhalten NullPointerException: bean does not exist . Konstruktorinjektion ist die beste Praxis, um Abhängigkeiten zu injizieren.

Answer 4

DI ist eine Teilmenge von IoC

• IoC bedeutet, dass Objekte keine anderen Objekte erzeugen, auf die sie angewiesen sind, um ihre Arbeit zu erledigen. Stattdessen erhalten sie die Objekte, die sie benötigen, von einem externen Dienst (z. B. einer XML-Datei oder einem einzelnen App-Dienst). 2 Implementierungen von IoC, die ich verwende, sind DI und ServiceLocator.
• DI bedeutet, dass das IoC-Prinzip, abhängige Objekte zu erhalten, ohne konkrete Objekte, sondern mit Abstraktionen (Schnittstellen) erfolgt. Dies macht alle Komponenten in einer Kette testbar, da eine Komponente auf höherer Ebene nicht von einer Komponente auf niedrigerer Ebene abhängig ist, sondern nur von der Schnittstelle. Mocks implementieren diese Schnittstellen.

Hier sind einige andere Techniken, um IoC zu erreichen .

Answer 5

IOC (Inversion der Kontrolle) : Die Übergabe der Kontrolle an den Container, um eine Instanz des Objekts zu erhalten, wird als Inversion der Kontrolle bezeichnet, d.h. anstatt dass Sie ein Objekt mit dem new-Operator erstellen, lassen Sie den Container das für Sie tun.

DI (Dependency Injection) : Die Art und Weise, wie Eigenschaften in ein Objekt injiziert werden, heißt Injektion von Abhängigkeiten .

Wir haben drei Arten von Injektion von Abhängigkeiten :

1. Konstruktor Injektion
2. Setter/Getter Injektion
3. Schnittstelle Injektion

Nur Federstützen Konstruktor Injektion et Setter/Getter Injektion .