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

Question

"L'injection de dépendances et l'inversion de contrôle sont souvent mentionnées comme les principaux avantages de l'utilisation du framework Spring pour le développement de frameworks Web.

Quelqu'un pourrait-il expliquer ce que c'est en termes très simples avec un exemple si possible ?

Answer 1

Printemps : Spring est un conteneur "d'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 selon laquelle le couplage d'objets est limité au moment de l'exécution par un objet "assembleur" et ne peut généralement pas être connu au moment de la compilation par une analyse statique.

Injection de dépendances (DI) : "L'injection de dépendances est un patron de conception logicielle qui permet de supprimer les dépendances codées en dur et de rendre possible leur modification, que ce soit à l'exécution ou à la compilation." -wiki.

Answer 2

En termes simples

• IOC (Inversion of Control) est un concept qui signifie : Au lieu de créer des objets avec le nouvel opérateur, laissez le conteneur le faire pour vous.
• DI (Dependency injection) est un moyen d'injecter la dépendance d'un composant de framework par les moyens suivants de Spring :

1. Injection de contructeur
2. Injection de Setter/Getter
3. injection de champ

Answer 3

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

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

Pour mieux 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 l'application et "appelle" le code/fonctions génériques ou réutilisables. Par exemple, dans une simple application Console, mon flux de contrôle est contrôlé par les instructions de mon programme, qui peuvent inclure les appels à certaines fonctions générales réutilisables.

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 cadres sont le code réutilisable qui "appelle" la logique métier.

Par exemple, dans un système basé sur Windows, un cadre 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. Lorsque j'écris la logique métier de mon application, ce sont les événements du framework qui appellent mon code de logique métier (lorsqu'un événement est déclenché) et NON l'inverse.

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

Ainsi, au lieu de faire dépendre le flux de contrôle d'objets liés statiquement, le flux dépend du graphe d'objets global et des relations entre les différents objets.

L'injection de dépendances est un modèle de conception qui met en œuvre le principe IoC pour résoudre les dépendances des objets.

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

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

L'injection de dépendances suggère qu'au lieu que la classe dépendante (ici la classe Car) crée ses dépendances (classe Engine et classe Tyre), la classe devrait être injectée avec l'instance concrète de la dépendance.

Comprenons avec un exemple plus pratique. Considérons que vous êtes en train d'écrire votre propre TextEditor. Entre autres choses, vous pouvez avoir un correcteur orthographique qui permet à l'utilisateur de vérifier les fautes de frappe dans son texte. Une implémentation simple 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 va écrire un texte. Le développeur capturera le texte et appellera la fonction CheckSpellings et trouvera une liste de coquilles qu'il montrera à l'utilisateur.

Tout semble fonctionner parfaitement jusqu'au jour où un utilisateur commence à écrire en français dans l'éditeur.

Pour fournir le support pour plus de langues, nous devons avoir plus de correcteurs orthographiques. Probablement le français, l'allemand, l'espagnol, etc.

Ici, nous avons créé un code étroitement couplé avec le correcteur d'orthographe "anglais" qui est étroitement couplé avec notre classe TextEditor, ce qui signifie que notre classe TextEditor est dépendante du correcteur d'orthographe "anglais" ou en d'autres termes, le correcteur d'orthographe "anglais" est la dépendance de TextEditor. Nous devons supprimer cette dépendance. De plus, notre éditeur de texte a besoin d'un moyen de tenir la référence concrète de n'importe quel vérificateur d'orthographe basé sur la discrétion du développeur au moment de l'exécution.

Ainsi, comme nous l'avons vu dans l'introduction de DI, il suggère que la classe soit injectée avec ses dépendances. Ainsi, 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 comme suit

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 doit recevoir l'instance concrète du type ISpellChecker.

Maintenant, la dépendance peut être injectée dans un constructeur, une propriété publique ou une méthode.

Essayons de modifier notre classe en utilisant Constructor DI. La classe TextEditor modifiée ressemblera à quelque chose comme ça :

Class TextEditor

{

    ISpellChecker objSpellChecker;

    string Text;

    public void TextEditor(ISpellChecker objSC)

    {

        objSpellChecker = objSC;

    }

    public ArrayList <typos> CheckSpellings()

    {

        return objSpellChecker.CheckSpelling();

    }

}

Ainsi, le code appelant, lors de la création de l'éditeur de texte, peut injecter le type de correcteur orthographique approprié à l'instance du TextEditor.

Vous pouvez lire l'article complet ici

Answer 4

L'IOC est une technique où vous laissez quelqu'un d'autre créer l'objet pour vous. Et ce quelqu'un dans le cas de Spring est le conteneur IOC.

L'injection de dépendances est une technique où un objet fournit la dépendance d'un autre objet.

Answer 5

IOC est l'abréviation de "inversion de contrôle". Il s'agit d'un concept de niveau supérieur qui stipule que le contrôle de la création d'objets est inversé de l'appelant vers le destinataire.

Sans inversion de contrôle, vous êtes en charge de la création des objets. Dans un scénario d'inversion de contrôle, un framework est chargé de créer des instances d'une classe.

L'injection de dépendances est la méthode par laquelle nous pouvons réaliser l'inversion de contrôle. Afin de laisser le contrôle au framework ou à la tâche, nous déclarons des dépendances et le conteneur IOC injecte ces dépendances dans notre classe (c'est-à-dire que le framework crée une instance pour nous et la fournit à notre classe).

Quels en sont les avantages ?

Tout d'abord, les classes et leur cycle de vie seront gérés par Spring. Spring gère complètement le processus de la création à la destruction.

Deuxièmement, vous obtiendrez un couplage réduit entre les classes. Une classe n'est pas étroitement couplée à une implémentation d'une autre classe. Si une implémentation change, ou si vous souhaitez modifier l'implémentation de l'interface injectée, vous pouvez le faire facilement sans avoir à modifier manuellement toutes les instances de votre base de code.

Troisièmement, il y a une cohésion accrue entre les classes. Une cohésion élevée signifie que les classes qui sont associées les unes aux autres restent ensemble. Comme nous injectons des interfaces dans d'autres classes, les classes nécessaires au fonctionnement de la classe appelante sont clairement identifiées.

Quatrièmement, la testabilité est accrue. Comme nous utilisons des interfaces dans le constructeur, nous pouvons facilement remplacer l'implémentation par une implémentation fantaisie.

cinquièmement, l'utilisation du JDK dynamic proxy pour proxyer des objets. Le JDK dynamic proxy requiert l'utilisation d'interfaces, ce qui est vrai, car nous injectons ces interfaces. Ce proxy peut ensuite être utilisé pour Spring AOP, la gestion des transactions, les données de Spring, la sécurité de Spring, etc.