Qu'est-ce que l'injection de dépendance et l'inversion du contrôle dans Spring Framework?

Je vais écrire ma simple compréhension de ces deux termes:

For quick understanding just read examples*

Injection de dépendance (DI):
L'injection de dépendance signifie généralement passer un objet dépendant en tant que paramètre à une méthode, plutôt que de demander à la méthode de créer l'objet dépendant.
Ce que cela signifie en pratique, c'est que la méthode n'a pas de dépendance directe sur une implémentation particulière; toute implémentation qui répond aux exigences peut être passée comme une paramètre.

Avec cela, les objets disent leurs dépendances. Et le printemps rend disponible.
Cela conduit à un développement d'applications faiblement couplé.

Quick Example:EMPLOYEE OBJECT WHEN CREATED,IT WILL AUTOMATICALLY CREATE ADDRESS OBJECT (if address is defines as dependency by Employee object)*.<br>

Inversion du conteneur de commande(IoC):
C'est une caractéristique commune des cadres, IOC gère les objets java
– de l'instanciation à la destruction en passant par son BeanFactory.
-Les composants Java instanciés par le conteneur IoC sont appelés beans, et le conteneur IoC gère la portée d'un bean, les événements du cycle de vie et toutes les fonctionnalités AOP pour lesquelles il a été configuré et codé.

QUICK EXAMPLE:Inversion of Control is about getting freedom, more flexibility, and less dependency. When you are using a desktop computer, you are slaved (or say, controlled). You have to sit before a screen and look at it. Using keyboard to type and using mouse to navigate. And a bad written software can slave you even more. If you replaced your desktop with a laptop, then you somewhat inverted control. You can easily take it and move around. So now you can control where you are with your computer, instead of computer controlling it.

En implémentant l'inversion de contrôle, un consommateur de logiciels/objets obtient plus de contrôles/options sur les logiciels/objets, au lieu d'être contrôlé ou d'avoir moins d'options.

L'inversion de la commande en tant que ligne directrice de conception sert les objectifs suivants:

Il y a un découplage de l'exécution d'une certaine tâche de application.
Chaque module peut se concentrer sur ce pour quoi il est conçu.
Les modules ne font aucune hypothèse sur ce que font les autres systèmes, mais s'appuient sur leurs contrats.
Le remplacement des modules n'a aucun effet secondaire sur les autres modules
Je vais garder les choses abstraites ici, Vous pouvez visiter les liens suivants pour une compréhension détaillée du sujet.
Une bonne lecture avec exemple

Explication Détaillée

Spring: Spring est un conteneur "Inversion de contrôle" pour la plate-forme Java.

Inversion de contrôle (IoC): L'inversion de contrôle (IoC) est une pratique de programmation orientée objet dans laquelle le couplage d'objet est limité à l'exécution par un objet "assembleur" et n'est généralement pas connu au moment de la compilation en utilisant l'analyse statique.

Dependency Injection (DI): "Dependency Injection est un modèle de conception logicielle qui permet la suppression des dépendances codées en dur et permet de modifiez-les, que ce soit au moment de l'exécution ou de la compilation."- wiki.

Dans Spring, les objets sont couplés de manière lâche, c'est-à-dire que chaque classe est indépendante l'une de l'autre afin que tout puisse être testé individuellement. Mais lors de l'utilisation de ces classes, une classe peut dépendre d'autres classes qui doivent être instanciées en premier. Donc, nous disons à spring que la classe A dépend de la classe B. Ainsi, lors de la création d'un bean(comme une classe) pour la classe A, il instancie la classe B avant celle de la classe A et l'injecte dans la classe A en utilisant des méthodes setter ou constructor DI. I. e., nous disons printemps la dépendance au moment de l'exécution. C'est DI. Comme nous attribuons la responsabilité de créer des objets(beans), de les maintenir et de leurs agrégations à Spring au lieu de les coder en dur, nous l'appelons Inversion De contrôle(IOC).

Inversion De Contrôle (IOC):

IoC est un modèle de conception qui décrit l'inversion du flux de contrôle dans un système, de sorte que le flux d'exécution n'est pas contrôlé par un morceau de code central. Cela signifie que les composants ne doivent dépendre que des abstractions d'autres composants et ne sont pas responsables de la gestion de la création d'objets dépendants. Au lieu de cela, les instances d'objet sont fournies à l'exécution par un conteneur IoC via l'injection de dépendance (DI).

Cio permet meilleure conception logicielle qui facilite la réutilisation, le couplage lâche et les tests faciles des composants logiciels.

Injection de dépendance (DI):

DI est une technique pour passer des dépendances dans le constructeur d'un objet. Si l'objet a été chargé à partir du conteneur, ses dépendances seront automatiquement fournies par le conteneur. Cela vous permet de consommer une dépendance sans avoir à créer manuellement une instance. Cela réduit le couplage et vous donne plus contrôle de la durée de vie des instances d'objet.

Cliquez pour voir plus de

Conteneur IoC

Le conteneur IoC est chargé d'instancier, de configurer et d'assembler les objets. Le conteneur IoC obtient des informations à partir du fichier XML et fonctionne en conséquence. Les principales tâches effectuées par IoC container sont:

• Pour instancier la classe d'application
• Pour configurer l'objet

• Pour assembler les dépendances entre les objets Il existe deux types de conteneurs IoC. Ils sont:

• BeanFactory

• ApplicationContext

Injection de dépendance (DI)

Dependency Injection (DI) est un modèle de conception qui supprime la dépendance du code de programmation afin qu'il puisse être facile à gérer et à tester l'application. L'injection de dépendance rend notre code de programmation faiblement couplé.

Spring framework fournit deux façons d'injecter la dépendance

• Par le constructeur
• Par Setter méthode

Inversion du contrôle- Cela signifie donner le contrôle de la création et de l'instanciation des beans spring au conteneur Spring IOC et le seul travail que le développeur fait est de configurer les beans dans le fichier xml spring.

Injection de dépendance -

Considérez un employé de classe

class Employee { 
   private int id;
   private String name;
   private Address address;

   Employee() {
     id = 10;
     name="name";
     address = new Address();
   }


}

Et considérons l'adresse de classe

class Address {
   private String street;
   private String city;

   Address() {
     street="test";
     city="test1";

  }
}

Dans le code ci-dessus, les valeurs de classe d'adresse ne seront définies que lorsque la classe Employee est instanciée, ce qui est la dépendance de la classe d'adresse sur Des employés de la classe. Et spring résout ce problème en utilisant le concept d'injection de dépendance en fournissant deux façons d'injecter cette dépendance.

1. Injection de Setter

Méthode Setter dans la classe Employee qui prend une référence de classe Address

public void setAddress(Address addr) {
    this.address = addr;
}

1. Injection de constructeur

Constructeur dans la classe Employee qui accepte l'adresse

Employee(Address addr) {
      this.address = addr;
}

De cette façon, les valeurs de classe d'adresse peuvent être définies indépendamment en utilisant l'un ou l'autre setter/constructeur injection.

La manière traditionnelle d'obtenir une instance d'adresse dans Employee serait de créer une nouvelle instance de classe d'adresse.Spring crée tous les objets dépendants nous donc nous n'avons pas à nous soucier de l'objet.

Donc, au printemps, nous dépendons simplement du conteneur spring qui nous fournit l'objet de dépendance.

L'inversion du contrôle est un principe de conception générique de l'architecture logicielle qui aide à créer des cadres logiciels réutilisables et modulaires faciles à maintenir.

C'est un principe de conception dans lequel le flux de contrôle est "reçu" de la bibliothèque générique écrite ou du code réutilisable.

Pour mieux le comprendre, voyons comment nous codions dans nos premiers jours de codage. Dans les langages procéduraux/traditionnels, la logique métier contrôle généralement le flux de application et "Appelle" le code/fonctions génériques ou réutilisables. Par exemple, dans une application Console simple, mon flux de contrôle est contrôlé par les instructions de mon programme, qui peuvent inclure les appels à certaines fonctions réutilisables générales.

print ("Please enter your name:");
scan (&name);
print ("Please enter your DOB:");
scan (&dob);

//More print and scan statements
<Do Something Interesting>

//Call a Library function to find the age (common code)
print Age

En revanche, avec IoC, les Frameworks sont le code réutilisable qui "Appelle" la logique métier.

Par exemple, dans un système Windows, un framework sera déjà disponible pour créer des éléments d'interface utilisateur tels que des boutons, des menus, des fenêtres et des boîtes de dialogue boîte. Lorsque j'écris la logique métier de mon application, ce sont les événements du framework qui appelleront mon code de logique métier (lorsqu'un événement est déclenché) et NON le contraire.

Bien que le code du framework ne connaisse pas ma logique métier, il saura toujours comment appeler mon code. Ceci est réalisé en utilisant des événements / délégués, des rappels, etc. Ici, le contrôle du flux est "Inversé".

Donc, au lieu de dépendre du flux de contrôle sur les objets liés statiquement, le flux dépend de la graphique d'objet global et les relations entre les différents objets.

Dependency Injection est un modèle de conception qui implémente le principe IoC pour résoudre les dépendances des objets.

En termes plus simples, lorsque vous essayez d'écrire du code, vous créerez et utiliserez différentes classes. Une classe (Classe A) peut utiliser d'autres classes (classe B et/ou D). Donc, les classes B et D sont des dépendances de la classe A.

Une simple analogie sera une Voiture de classe. Une voiture peut dépendre d'autres classes comme le moteur, les pneus et plus encore.

Dependency Injection suggère qu'au lieu des classes dépendantes (Class Car ici) créant ses dépendances (Class Engine et class Tyre), class devrait être injecté avec l'instance concrète de la dépendance.

Permet de comprendre avec un exemple plus pratique. Considérez que vous écrivez votre propre TextEditor. Entre autres choses, vous pouvez avoir un correcteur orthographique qui fournit à l'utilisateur une possibilité de vérifier les fautes de frappe dans son texte. Simple la mise en œuvre d'un tel code peut être:

Class TextEditor
{

    //Lot of rocket science to create the Editor goes here

    EnglishSpellChecker objSpellCheck;
    String text;

    public void TextEditor()

    {   

        objSpellCheck = new EnglishSpellChecker();

    }

    public ArrayList <typos> CheckSpellings()
    {

        //return Typos;

    }

}

, À première vue, tout semble rose. L'utilisateur écrira du texte. Le développeur capturera le texte et appellera la fonction CheckSpellings et trouvera une liste de fautes de frappe qu'il montrera à l'utilisateur.

Tout semble bien fonctionner jusqu'à un beau jour où un utilisateur commence à écrire le français dans l'éditeur.

Pour prendre en charge plus de langues, nous devons avoir plus de correcteurs orthographiques. Probablement Français, Allemand, Espagnol etc.

Ici, nous avons créé un code étroitement couplé avec "English"SpellChecker étant étroitement couplé avec notre classe TextEditor, ce qui signifie que notre classe TextEditor dépend du EnglishSpellChecker ou en d'autres termes EnglishSpellCheker est la dépendance de TextEditor. Nous devons supprimer cette dépendance. De plus, Notre éditeur de texte a besoin d'un moyen de contenir la référence concrète de tout correcteur orthographique basé sur la discrétion du développeur au moment de l'exécution.

Donc, comme nous l'avons vu dans l'introduction de DI, il suggère que la classe devrait être injectée avec ses dépendances. Donc, il devrait être de la responsabilité du code appelant d'injecter toutes les dépendances à la classe/code appelé. Nous pouvons donc restructurer notre code en

interface ISpellChecker
{

    Arraylist<typos> CheckSpelling(string Text);

}

Class EnglishSpellChecker : ISpellChecker

{

    public override Arraylist<typos> CheckSpelling(string Text)

    {

        //All Magic goes here.

    }

}



Class FrenchSpellChecker : ISpellChecker

{

    public override Arraylist<typos> CheckSpelling(string Text)

    {

        //All Magic goes here.

    }

}

Dans notre exemple, la classe TextEditor devrait recevoir l'instance concrète de type ISpellChecker.

Maintenant, la dépendance peut être injectée dans un Constructeur, une Propriété Publique ou une méthode.

Essayons de changer notre classe en utilisant le constructeur DI. Modifié La classe TextEditor ressemblera à quelque chose comme:

Class TextEditor

{

    ISpellChecker objSpellChecker;

    string Text;



    public void TextEditor(ISpellChecker objSC)

    {

        objSpellChecker = objSC;

    }



    public ArrayList <typos> CheckSpellings()

    {

        return objSpellChecker.CheckSpelling();

    }

}

Afin que le code appelant, lors de la création de l'éditeur de texte, puisse injecter le type de correcteur orthographique approprié à l'instance de l'éditeur de texte.

, Vous pouvez lire l'article complet ici