L'injection de dépendances dans le développement par classe

Résumé du document

Les applications devenant de plus en plus complexes, de plus en plus lourdes à programmer, il est très rapidement nécessaire d'organiser le code source de manière structuré. Une bonne architecture est de pouvoir réduire au maximum le couplage entre les classes, de séparer des modules en couches, de permettre un travail en parallèle de différentes équipes.

Extraits

[...] Il faut donc gérer la création de l'objet c2 (instance de C2) et l'injection à un objet c1 (instance de C1) ; pour cela, deux manières : c2 serait un argument du constructeur de C1 c2 serait un argument d'une méthode de C La simplification des tests unitaires Un intérêt tout particulier de l'injection de dépendance vient de la vérification des classes qui devient beaucoup plus facile, puisque les classes peuvent désormais interagir sans dépendance. Il n'est plus nécessaire de tester une logique métier à l'aide d'objets ou services existants, ces derniers pouvant d'ailleurs entraîner des erreurs vis-à-vis de leurs classes qui n'ont pas encore été vérifiées. Il suffira de se servir de souches (stubs) ou de bouchons (mocks) qui implémentent la même interface mais qui se comportent uniquement de la "meilleure" manière : celle que l'on a choisie ! [...]

[...] Ces trois approches ont en commun la résolution des dépendances mais diffèrent principalement dans leur utilisation selon le cas rencontré. Dans l'optique d'améliorer le premier exemple, j'utiliserais une classe "FileFinder" ; permettant de trouver des fichiers à partir d'un filtre : public class FileFinder { IFilter filter; . } 2.1 Injection par interface L'injection par interface correspond à l'IoC de type 1. C'est une méthode intrusive : chaque composant doit implémenter une interface qui sera utilisée pour supprimer les dépendances à l'implémentation. [...]

[...] public void Inject(Object target) { ((InjectFilter) target).InjectFilter(this); } } Cette méthode est plutôt lourde à mettre en place ; la lisibilité du code décroit avec le nombre d'interfaces crées. La configuration elle-même devient encore plus complexe à réaliser. On lui préfèrera donc les deux méthodes suivantes, plus pertinentes Injection par accesseur L'injection par accesseur (ou injection par mutateur) correspond à l'IoC de type 2. C'est une méthode non intrusive : chaque composant définit un membre privé pour l'objet auquel il dépendra ; un accesseur (setter) est chargé d'affecter la valeur du membre. public class FileFinder { . [...]

[...] Généralités 1.1 Définitions L'injection de dépendance est une technique de programmation où une classe n'est pas responsable dans l'instanciation des autres classes dont elle a besoin. Les objets sont "injectés" au moment de la construction ou de l'initialisation de l'objet qui les utilise. L'injection de dépendance est plus généralement nommée "inversion de contrôle" (IoC) ; le contrôle n'opère pas au niveau de la classe appelante mais d'une nouvelle classe supplémentaire (son instance est appelé "assembleur"), uniquement chargée d'initialiser les dépendances. [...]

[...] C'est une méthode non intrusive : chaque composant définit un membre privé pour l'objet auquel il dépendra ; un constructeur est chargé de lui affecter sa valeur. public class FileFinder { . public FileFinder(IFilter filter) { this.filter = filter; } } L'avantage est la disponibilité immédiate du membre privé dès la création de l'objet ; avec une bonne encapsulation des objets dépendants. En revanche, le constructeur peut être surchargé, ce qui peut réduire la lisibilité. Conclusion L'injection de dépendance répond à un besoin de flexibilité et surtout de maintenabilité du programme. [...]