Salut et bienvenue dans ce nouvel épisode du podcast de Code Garage,
je m'appelle Nicolas Bernard Bernard et aujourd'hui on va parler d'injection de dépendance.
Alors l'injection de dépendance, en anglais on va parler de dependency injection
ou parfois vous trouverez l'acronyme DI,
et ben c'est simplement un vrai principe clé dans le développement logiciel
et c'est aussi assimilé à une bonne pratique
parce que vous allez voir que ça va nous permettre de faire des choses
qui ne seraient pas possibles autrement.
Alors avant de rentrer dans les termes techniques,
on va d'abord commencer par une petite, une espèce d'allégorie
pour essayer de vous faire comprendre si jamais vous ne connaissez pas du tout ce concept.
On va prendre une code base qui n'a pas d'injection de dépendance
et on va le transposer dans votre machine à café,
dans votre entreprise, à l'école, peu importe.
Vous savez c'est grosse machine à café, il y a plein de marques différentes
et puis vous pouvez simplement appuyer sur un bouton,
mettre votre argent et vous trouvez votre café.
Ben ça c'est un peu une code base sans injection de dépendance.
Pourquoi ? Parce que tout simplement, si vous voulez un café
qui n'est pas prévu directement dans la machine,
eh bien c'est pas possible.
Si jamais vous voulez potentiellement même mettre votre mug,
et ben parfois sur certaines machines, c'est pas possible non plus
puisque le petit gobelet tombe tout seul
et sinon il va tomber dans votre mug.
Enfin bref, il y a plein de problèmes
et surtout quand il va falloir recharger le café, etc.
Et ben là vous allez devoir faire appel à un technicien
qui modifie l'intérieur de la machine,
qui remplisse les trucs, etc.
Ça c'est notre code base, et bien sans injection de dépendance.
Qu'est-ce que serait une injection de dépendance dans notre code base ?
Eh bien ce serait plutôt la machine,
par exemple je prends une marque ozare mais n'est-ce presseau,
que vous avez chez vous,
ou c'est vous qui allez venir donner votre petit pod de café
et mettre votre tasse, etc.
Sachant qu'aujourd'hui,
et bien évidemment il y a plein de pods différents
faites par des marques différentes
et qui sont compatibles avec la machine.
Ok, vous n'avez pas besoin d'avoir le pod n'espresso,
vous pouvez avoir des pods avec plein de marques différentes
qui sont écologiques, recyclables,
et peut-être même, j'en sais rien,
des pods spéciaux qui ne contiennent pas du café,
mais un espèce de produit
pour nettoyer votre machine tous les mois, deux mois, etc.
Je ne sais pas si ça existe,
mais je ne vois pas de café, désolé,
mais en tout cas j'imagine que ça peut exister.
Voilà ce que ça donnerait l'injection de dépendance
dans la vraie vie,
si on le transforme en machine à café,
c'est qu'il y en a une qui est figée,
elle est obligée de fonctionner de telle manière,
puisque tout est déjà dedans, les gobelets, le café, etc.
et si on veut changer quelque chose,
on est obligé d'ouvrir et de complètement modifier
le contenu de la machine,
alors que l'autre, elle fait simplement la fonction,
faire chauffer de l'eau, d'ailleurs on met notre eau aussi,
alors que dans la machine à café de base,
il faut que ça soit alimenté directement par un tuyau, etc.
Là on vient mettre notre eau, mettre notre pod,
mettre notre tasse, etc.
Et donc on peut faire du café, on peut faire du thé,
on peut faire de plein de choses,
tant qu'on trouve des capsules qui sont compatibles.
C'est exactement ça l'injection de dépendance.
Dans une application,
une dépendance c'est simplement un objet
dont un autre objet a besoin pour fonctionner.
Par exemple, un service de gestion de commande
dans un city commerce,
il a besoin d'un service qui va faire de la facturation
ou un service d'envoi d'email,
il a besoin de tout plein de services,
un service de gestion d'utilisateur, etc.
Et plutôt que de créer ces objets,
donc ces instances de service directement
dans notre classe, par exemple commande,
enfin dans le service commande,
on va les injecter depuis l'extérieur.
Donc par exemple, vous avez un order service,
au lieu d'avoir par exemple,
this.emailService,
égal, new email service,
directement dans le constructeur de ce service,
et bien en fait,
votre constructeur va attendre un paramètre
et ce paramètre, ça va être une instance,
alors souvent même une instance d'une interface,
par exemple e-emailService,
et donc là peu importe qu'elle va être
notre provider d'envoi d'email derrière,
tant que le service qu'on va lui injecter
est compatible avec l'interface qu'il attend,
et bien ça va forcément fonctionner.
Et alors pourquoi est-ce que c'est vraiment game changer
dans une codebase notamment,
enfin du logiciel,
donc ça peut être du backend, du front-end, peu importe.
La première chose évidemment c'est le découplage,
parce que ça veut dire que chaque classe
se concentre sur ce qu'elle doit faire,
sans se soucier des détails,
des créations des objets qu'elle utilise,
qu'est-ce qu'il faut pour l'instant si est-elle service, etc.
qu'est-ce qu'il faut avoir accès à la base de données,
voilà tout ça il n'y a pas besoin de s'en occuper.
Ensuite, c'est évidemment la testabilité,
puisque on va pouvoir très facilement remplacer
un service réel on va dire,
par un faux service, un mock,
pour faire des tests unitaires,
ou des tests même d'intégration, peu importe.
Évidemment la flexibilité j'en ai parlé,
mais ça veut dire qu'on va pouvoir facilement remplacer
une implementation, donc par exemple vous utilisez MailChimp
pour votre service d'email,
et puis là vous allez vouloir utiliser
SendinBlue par exemple qui s'appelle Brevo maintenant,
et bien ça c'est possible,
sans avoir à modifier le reste du code,
tant que votre nouveau service
il implémente la même interface de base
avec les mêmes fonctions et les mêmes données disponibles,
et bien ça fonctionnera tout pareil.
Et évidemment c'est plus facile de réutiliser du code,
parce qu'un service qui est bien découplé,
il est facilement utilisable dans plein d'autres contextes,
dans d'autres services, dans d'autres... plein de choses.
Alors là l'injection de dépendance
elle peut se faire de deux manières,
elle peut se faire manuellement,
on peut dire simplement qu'on va toujours passer
les objets au constructeur de nos services,
et c'est nous qui allons le faire à la main,
mais en général la meilleure des pratiques c'est
d'avoir un conteneur d'injection de dépendance
qui est très souvent fourni par le frémoire,
ou en tout cas par une bibliothèque éventuellement au-dessus
qui va gérer tout ça, et qui va se charger
de créer et d'assembler les objets automatiquement.
Donc en général ce que vous allez faire
c'est que vous allez déclarer à la fois une interface
et vous allez injecter,
enfin vous allez décider de quel service va être instantié
et qui correspond à votre interface
et du coup ça sera rendu disponible
tant que vous le déclarer en fait
dans le constructeur de vos autres services
qui l'attend une implémentation de cette interface-là
et bien l'injection de dépendance va se faire
automatiquement et de manière indépendante.
Donc voilà, en résumé c'est vraiment un principe
de conception qui est très très simple,
mais ça a des conséquences énormes
sur la qualité du code, la clarté
et la robustesse à long terme
de n'importe quel projet logiciel
et franchement si vous avez jamais travaillé
avec des outils qui font de l'injection de dépendance
notamment de l'injection automatique
sincèrement essayez de trouver dans votre langage
avec les frémoires que vous utilisez déjà
des outils qui sont compatibles
parce que ça va vraiment vous faciliter la vie.
A titre personnel, j'ai découvert ça
on va dire dans le monde réel chez un client
qui fait encore d'ailleurs du C-Sharp
avec Dutnet Core en back-end
et cas de l'injection automatique de dépendance
et très sincèrement mais c'est trop dur
de revenir en arrière.
Donc maintenant j'essaye d'avoir ça
dans tous mes projets à chaque fois que je peux.
J'espère que cet épisode vous aura plu
que vous aurez appris quelque chose
je vous donne rendez-vous la semaine prochaine
pour un prochain épisode du podcast
pensez à mettre 5 étoiles sur
Deezer, Spotify, Apple Podcast, peu importe
où vous écoutez, ça permet d'améliorer
le référencement du podcast et de soutenir
notre travail et sinon évidemment
rendez-vous sur code-tarigarage.com
Il y a plein de choses qui arrivent en juillet
on a, là on approche de fin juillet
mais ça arrive très très très bientôt
les challenges de code qui arrivent
sur la plateforme donc un petit peu
à la manière de code in game, de code or pas
des choses comme ça, vous allez pouvoir
vous tester sur les connaissances
de vos langages préférés et vous allez pouvoir
le faire apparaître sur votre profil
voilà ça va permettre d'agrémenter
un petit peu tout votre profil
avec des compétences qu'on a validées
sur la plateforme puisque vous aurez réussi
les challenges. Je vous donne rendez-vous
la semaine prochaine pour un prochain épisode
prenez soin de vous, salut !