Qu'est-ce que l'injection de dépendances et quel problème résout-elle réellement ?

L'injection de dépendances veut dire qu'un composant reçoit ses collaborateurs de l'extérieur au lieu de les construire lui-même. Le problème qu'elle résout, c'est le couplage : si une classe crée son propre client de base de données, vous ne pouvez pas le remplacer, la tester isolément, ni contrôler sa durée de vie. Passer les dépendances par le constructeur les rend explicites, rend la classe honnête sur ce qu'elle touche, et vous laisse fournir un faux en test ou une implémentation différente par environnement.

Ça veut simplement dire qu'on donne à une classe ce dont elle a besoin au lieu qu'elle le fabrique. Si mon service de commandes construit son propre client Postgres dans le constructeur, il est soudé à Postgres et à la chaîne de connexion présente dans l'environnement, et tout test de cette classe devient un test d'intégration. S'il prend une interface de dépôt en paramètre de constructeur, je passe la vraie en production et une en mémoire en test, et la classe s'en moque. Le bénéfice que j'ai appris à valoriser davantage avec le temps, c'est l'honnêteté : la signature du constructeur vous dit exactement ce que cette chose touche, donc quand une classe prend sept dépendances, c'est un défaut de conception qui se voit plutôt qu'un défaut qu'on va chercher. Je veux être clair sur le fait que je ne pense pas qu'il faille un conteneur. Sur les petits services, je câble tout à la main dans un seul fichier de composition, et ce fichier devient la carte du système. Les frameworks aident une fois que le câblage devient fastidieux, pas avant.