Bien qu’ayant découvert tardivement l’inversion de contrôle et le principe d’injection de dépendance, je me demande aujourd’hui comment faire un développement cohérent et un projet un tant soit peu maintenable et réutilisable sans ?
Le cas fréquent des développements est d’arriver à une application :
- Rigide
- Fragile
- Immobile
- Invérifiable
L’IOC (Inversion Of Control) et plus particulièrement l’injection de dépendances apporte des réponses à ces problèmes. Je propose donc de faire un rappel sur l’IOC et sur le DIP (Dependency Injection Principle) et surtout de bien présenter la différence entre les deux (chose qui a très longtemps été un mystère pour moi).
Tout d’abord, pour bien comprendre l’IOC il faut comprendre que l’IOC est un design-pattern et qu’il a pour but de supprimer le schéma classique de dépendance que peuvent avoir deux classes entre elles :
Schéma « classique »
Dépendance par une interface.
Maintenant que nous avons vu ce qu’était l’IOC, tachons de comprendre la différence entre IOC et DIP. Pour ce faire je vais reprendre un schéma tiré du livre « Building Spring2 Enterprise Applications » (rendons à César ce qui appartient à César) :
Le schéma montre bien que l’injection de dépendance est une forme d’inversion de contrôle. L’autre forme d’IOC, appelée Dependency lookup, a pour exemple en Java JNDI. JNDI est un annuaire de nommage, qui permet de retrouver des objets à partir d’un nom. Cette forme est devenue le moyen standard de résoudre les dépendances en J2EE, cependant, étant contrôlée par l’application elle nécessite encore d’effectuer du « code glue ».
L’injection de dépendance laisse, quand à elle, le soin de l’injection au conteneur IOC. Les dépendances sont externalisées par configuration. Il existe trois forme d’injection de dépendance : l’injection par interface (ex : Apache Avalon) qui n’est plus trop à la mode, l’injection par constructeur (ex : Pico Conteneur) et enfin l’injection par Setter ou encore appelé injection par Mutateur (ex : Spring). A noter que Spring supporte aussi l’injection par constructeur, mais l’injection par Setter lui est préféré.
Article de référence en la matière : Site de Martin Fowler
décembre 6th, 2007 at 14:45
Un p’tit exemple concret n’aurait pas fait de mal je pense
décembre 6th, 2007 at 15:04
tu parles dans le vent avec des mots pipeaux au lieu d’expliquer ces deux concepts simples de manière simple
décembre 6th, 2007 at 22:00
OK, prochain article des exemples
octobre 24th, 2008 at 22:18
J’ai rien compris à ton explication : c’est encore plus flou maintenant !
Est-ce possible de la refaire avec des mots et et exemples simples et concrets ?
août 28th, 2009 at 10:18
Je te remercie de cette explication, pouvez vous m’envoyer un exemple concret sur IOC et les DIP?
janvier 18th, 2010 at 14:25
J’avoue qu’à partir de la seconde moitié, je ne comprends plus rien (le schéma ne me semble pas adéquat car aucun rapport avec la philosophie du premier).
Bonne continuation.
juin 16th, 2010 at 14:25
En effet me voilà tombé sur cet article pour comprendre comment faire l’injection de dépendance (parce qu’il faut reconnaître que l’implémentation réalisé par Google est plutôt complexe, du genre une centaine de classes…).
Je cherche à m’y retrouver entre Injector, Provider, TypeLiteral, etc. Et là ? Et bien aucune explication, tu restes extrêmement vague et au final on comprend uniquement que ça revient à mettre une interface au milieu d’une dépendance :S
juillet 2nd, 2010 at 10:38
ouaip … j’ai rien compris !!