Excellente explication de l'injection de dépendance (inversion de contrôle)

J'ai lu beaucoup d'explications sur l'Injection de Dépendance ou DI (anciennement appelée Inversion de Contrôle) et le Principe d'Hollywood associé ("Ne nous appelez pas, nous vous appellerons."). Ils ont tous tendance à ne pas être clairs, soit parce qu'ils plongent immédiatement dans des explications très détaillées, soit parce qu'ils lient l'explication spécifiquement à une technologie particulière. De telle sorte que soit le motif est perdu, soit sa simplicité l'est. Voici l'explication la plus claire que j'ai trouvée - légèrement modifiée par souci de brièveté (tirée du très bon Spring in Action, 2e éd. Par Craig Walls):

"Toute application non triviale est constituée de deux classes ou plus qui collaborent entre elles pour exécuter une logique métier. Traditionnellement, chaque objet est responsable de l'obtention de ses propres références aux objets avec lesquels il collabore (ses dépendances). Lors de l'application de DI, le Les dépendances sont données aux objets au moment de leur création par une entité externe qui coordonne chaque objet du système. En d'autres termes, les dépendances sont injectées dans les objets. "

Je trouve cela très clair.

L'injection de dépendances s'appelait à l'origine Inversion of Control (IoC) car la séquence de contrôle normale serait que l'objet trouve les objets dont il dépend par lui-même, puis les appelle. Ici, cela est inversé: les dépendances sont transmises à l'objet lors de sa création. Cela illustre également le principe d'Hollywood au travail: ne faites pas appel à vos dépendances, nous vous les donnerons lorsque nous aurons besoin de vous.

Si vous n'utilisez pas DI, vous vous demandez probablement pourquoi c'est un gros problème. Il offre un avantage clé: un couplage lâche. Les objets peuvent être ajoutés et testés indépendamment des autres objets, car ils ne dépendent de rien d'autre que de ce que vous leur transmettez. Lorsque vous utilisez des dépendances traditionnelles, pour tester un objet, vous devez créer un environnement dans lequel toutes ses dépendances existent et sont accessibles avant de pouvoir le tester. Avec DI, il est possible de tester l'objet de manière isolée en lui passant des objets simulés pour ceux que vous ne voulez pas ou n'avez pas besoin de créer. De même, l'ajout d'une classe à un projet est facilité car la classe est autonome, donc cela évite la "grosse boule de poils" dans laquelle les grands projets évoluent souvent.

Le défi de DI est d'écrire une application entière en l'utilisant. Quelques cours ne sont pas un problème, mais une application entière est beaucoup plus difficile. Pour des applications entières, vous souhaitez souvent qu'un framework gère les dépendances et les interactions entre les objets. Les frameworks DI sont souvent pilotés par des fichiers XML qui aident à spécifier ce qu'il faut transmettre à qui et quand. Spring est un framework Java DI à service complet; d'autres cadres DI plus légers incluent NanoContainer et le PicoContainer encore plus léger.

La plupart de ces frameworks ont de bons tutoriels pour aider les débutants à trouver leur chemin.

Cette histoire, «Excellente explication de l'injection de dépendances (inversion de contrôle)» a été initialement publiée par JavaWorld.