Ouarzy's Blog

Je suis récemment tombé sur un article sympathique essayant d’expliquer le plus simplement possible l’injection de dépendance: http://petitcodeur.fr/php/injection-dependance.html

J’ai trouvé cet article clair, mais pas si simple que ça à appréhender pour un néophyte de l’injection. Cela m’a donc inspiré cet article dans lequel je vais tenter d’expliquer l’injection de dépendance (encore plus) simplement.

La testabilité
Pour moi les problématiques d’injection sont parfaitement révélées par la testabilité. Quand on souhaite rendre une application testable unitairement, on est naturellement confronté à cela.

Cas non testable
Prenons une application extrêmement classique, séparant sa couche métier de sa couche d’accès aux données. La couche métier utilise l’accés aux données pour récupérer ses informations dans une base de données. Maintenant admettons que l’on déclare directement dans la couche d’accès aux données, la façon concrète dont on accède aux données (pour notre exemple: l’instanciation d’un web service)

Nous sommes typiquement sur un cas ou la classe Metier ne sera pas testable unitairement, puisque si on l’utilise dans un test unitaire, elle va implicitement déclarer un WebService qui est lui-même dépendant d'une base de données. Techniquement il est donc envisageable de tester la chaine complète, mais on est alors très loin du test unitaire ! (on est au mieux sur un test d’intégration : on valide le fonctionnement métier lié à une BDD)

Cas testable

Maintenant imaginons que la couche métier précise à la couche d’accès aux données quel interface de service elle doit utiliser (typiquement, en lui injectant l’interface du service via le constructeur). Cela change alors tout, puisqu’on va pouvoir choisir à l’exécution quelle implémentation on souhaite utiliser pour la couche d’accès aux données (typiquement géré avec un conteneur d’injection de dépendances)

On pourra alors implémenter l’interface IService avec le vrai WebService en fonctionnement normal, ou avec un Mock du service pour les tests unitaires (ce qui nous affranchit alors totalement de la BDD). Notez au passage qu’on pourrait très bien avoir d’autres implémentations de IService (qui pourrait récupérer leurs infos dans une autre BDD, un autre type de SGBD ou même dans un fichier XML...Tiens ce serait pas ce qu'on apelle du découplage?)

Conclusion

Rien de magique ici, juste une tentative pour expliquer que l’injection de dépendance c’est très simple : on fournit aux objets les interfaces dont ils ont besoin dans leur constructeur, ce qui permet de modifier leur comportement facilement à l'exécution. Le test unitaire est une bonne façon de voir  l'importance d'utiliser des interfaces.

Mais c'est surtout une bonne façon de voir la différence de comportement attendu par une couche d’accès aux données, en fonction du contexte d’exécution (test ou production par exemple).