Inversion de contrôle et injection de dépendances en Java / Spring

Table des matières
Il s'agit de la quatrième partie d'une série de tutoriels axés sur la révision des sujets de base du langage Java pour préparer le lecteur à l'utilisation de Spring Framework. La première partie de cette série de tutoriels peut être obtenue ici, la deuxième partie peut être obtenue ici et la troisième partie ici. Dans ce tutoriel, nous verrons 2 concepts de base que nous devons gérer si nous voulons utiliser Spring correctement : l'inversion de contrôle et l'injection de dépendances.
Tout d'abord, je tiens à préciser que ces concepts sont bien mieux expliqués par Martin Fowler dans cet article et traduits en espagnol sur cette page mais mon intention est d'essayer de résumer le concept pour le rendre facilement compréhensible et vous éviter un peu de lecture du article (bien que vous soyez cordialement invités à le lire si vous avez d'autres questions).
Le terme est relativement récent, mais il s'agit d'un modèle de programmation qui remonte à ces programmes créés à l'aide de la programmation séquentielle pure, où un seul programmeur (ou groupe de programmeurs) s'asseyait pour écrire une série d'étapes ou d'instructions de calcul à effectuer en parfait du début à la fin avec l'intention d'obtenir un dernier résultat.
A cette époque (ne pense pas que c'était il y a de nombreuses années), les appels aux méthodes et aux bibliothèques provenaient toujours d'une source centrale qui était chargée de manipuler toutes les variables dans le même programme. Plus tard, des interfaces graphiques ont été développées qui étaient chargées de gérer les entrées de données dans le programme, tandis que le flux principal du programme était chargé de fournir des gestionnaires pour les événements qui se sont produits dans l'interface graphique (active quelque chose en cliquant, en appuyant sur cette touche , déplacement de la souris, etc.) alors que l'interface est en boucle constante. De cette façon, le contrôle du programme est inversé, l'interface graphique est chargée de notifier le flux principal de ce qu'il faut faire et comment sans avoir besoin de savoir exactement COMMENT cela est fait.
Si vous remarquez, les interfaces en Java peuvent vous aider à transférer le contrôle d'une application à des agents externes, mais le concept s'applique aux threads démons qui attendent qu'un événement se produise, une classe qui est responsable de l'instanciation et de la livraison des implémentations d'autres classes à le programme (modèle d'usine) et essentiellement tout modèle qui permet de transmettre le contrôle du programme à un agent externe.
Il s'agit d'un type particulier d'Inversion de Contrôle dans lequel une classe A ne sait pas quel objet elle va utiliser au moment de sa compilation, mais ne connaît que les actions qu'elle doit entreprendre avec cet objet. Supposons la classe suivante (qui est basée sur les classes créées dans mon tutoriel précédent) :
 classe publique dessinateur {place publique; Caricaturiste public () {carré = nouveau Carré (); } public void MasterDraw () {square.Draw (); }} 

Comme vous le verrez, cette classe "Draftsman" dépend entièrement de la classe "Square" puisqu'elle est en charge du cycle de vie de l'objet carré qu'elle utilisera par la suite. Cette façon de créer une classe "Draftsman" est très peu pratique car si plus tard nous voulions que le Draftsman dessine des rectangles ou des triangles, nous devrons modifier le code de base pour le faire.
Au lieu de cela, nous pouvons créer une classe plus réutilisable si nous implémentons l'interface "Drawable" que nous avons créée dans le tutoriel précédent :
 classe publique Dessinateur {dessin dessinable public; dessinateur public (dessinable d) {dessin = d; } public void MasterDrawing () {dessin.Drawing (); }} 

De cette façon les objets de la classe "Draftsman" ne "contrôlent" pas l'objet qu'ils doivent dessiner mais savent seulement qu'il implémente l'interface Drawable et, plus tard, ces objets "Draftsman" que je créerai dans mon application ou que quelqu'un else va être utilisé dans une application qui accède à ma bibliothèque d'objets, ils sont parfaitement capables de recevoir n'importe quel objet qui implémente l'interface "Drawable".
Dans l'exemple précédent, nous appliquons ce que l'on appelle "Constructeur Inyection" puisque la dépendance est injectée au niveau du constructeur mais vous pouvez également injecter la dépendance via les "Setters" ou, dans d'autres langages de programmation, vous pouvez injecter les paramètres ou les interfaces (En Java, vous ne pouvez pas modifier les paramètres ou les interfaces qui accepte une méthode au moment de l'exécution, mais Python, par exemple, permet aux méthodes d'accepter des paramètres sans spécifier le type des paramètres.)
 classe publique Dessinateur {dessin dessinable public; public void setDrawing (Drawable d) {dessin = d; } public void MasterDrawing () {dessin.Drawing (); }} 

La injection de dépendance permet essentiellement une séparation des fonctionnalités de votre programme. Cette indépendance vous permet de tester vos cours sans (la peine de le répéter) que votre cours soit lié à quoi que ce soit. Cette indépendance est l'une des pièces maîtresses à utiliser Le printemps, les composants dépendent du framework et non de l'application, vous pouvez créer des objets qui existent en dehors de votre application et les utiliser uniquement lorsque vous en avez besoin.
À partir du prochain tutoriel, nous commencerons à travailler directement avec Spring et vous verrez comment tous les concepts que nous avons vus jusqu'à présent sont liés à son fonctionnement et vous permettront d'acquérir l'expertise nécessaire en peu de temps.
J'attends vos commentaires, Jusqu'à la prochaine fois !Avez-vous aimé et aidé ce tutoriel ?Vous pouvez récompenser l'auteur en appuyant sur ce bouton pour lui donner un point positif

Vous contribuerez au développement du site, partager la page avec vos amis

wave wave wave wave wave