Salut,
Je viens de lire la page Wikipédia sur l'injection de dépendances ( http://fr.wikipedia.org/wiki/Injection_de_d%C3%A9pendances ) et du coup je me demandais si passer un objet en paramètre à une méthode consistait en une injection de dépendances ?

Par exemple en Java :

class A {
....printB(B monB) {
........monB.methodeDeB();
}

si on suppose que B est une interface définissant la méthode methodeDeB(); ça consiste en une injection de dépendances ? Ou il faut absolument que l'instance de B soit "sauvegardée" (ie. dans un attribut) ?

Car dans les exemples sur le Wiki En ( http://en.wikipedia.org/wiki/Dependency_injection ) l'objet est toujours passé soit au constructeur, soit à un setter, jamais à une méthode classique Pourquoi ?

Hello,
Oui en effet, l'idée de l'injection de dépendance c'est que la classe possède des références vers les services qu'elle utilise.

La façon propre de le faire c'est de passer les services par le constructeur, l'injection par setter c'est possible mais assez discutable au niveau conception (je développe si tu veux).

Effectivement, si tu passes un service en paramètre d'une méthode et que tu t'en sers une fois, c'est pas réellement de l'injection de dépendance au sens bien compris même si les avantages que ça procure peuvent être sensiblement identiques.

| https://www.jeuxvideo.com/forums/1-47-111522-1-0-1-0-passage-d-argument-injection-de-depend.htm#message_111526
| Ecrit par « _skip », 19 novembre 2014 à 13:15:18
| « Effectivement, si tu passes un service en paramètre d'une méthode et que tu t'en sers une fois, c'est pas réellement de l'injection de dépendance au sens bien compris même si les avantages que ça procure peuvent être sensiblement identiques. »

D'accord, merci

| https://www.jeuxvideo.com/forums/1-47-111522-1-0-1-0-passage-d-argument-injection-de-depend.htm#message_111526
| Ecrit par « _skip », 19 novembre 2014 à 13:15:18
| « l'injection par setter c'est possible mais assez discutable au niveau conception (je développe si tu veux). »

Je veux bien si tu as du temps. Je dirais que passer par le setter plutôt que par le constructeur laisse l'objet dans un état potentiellement incohérent le temps que les setters soient appelés (risque de NullPointerException en Java) ? Dans ce cas il faudrait peut-être coupler au pattern builder par exemple si on veut utiliser l'injection de dépendances par setters (ou simplement s'assurer que l'objet soit utilisable même si le setter n'a pas été appelé) ?

En fait la justification pour utiliser un setter, ce serait que la dépendance injectée soit facultative (au sens où la classe est 100% fonctionnel sans, sans exception ou effet de bord), cela dit c'est loin d'être souvent le cas.

Cependant, l'injection par setter s'est démocratisée avec les conteneurs IOC, c'est à dire des outils comme Spring ou Guice qui peuvent construire des objets et injecter leurs attributs selon une configuration pré-établie. Le développeur peut affirmer avec plus ou moins d'assurance que les classes ne seraient jamais instanciées à l'aide d'un new, elles peuvent même avoir un constructeur par défaut non public pour s'en assurer.
Mais en général, il y a peu de justifications de nos jours de ne pas laisser les dépendances dans le constructeur, et évt de les déclarer private final.

Comme tu l'expliques très bien, c'est rarement une bonne idée de risquer de laisser des objets dans un état de merde après la construction. Quant au builder... ça t'amène pas forcément grand chose par rapport à une factory car tu as rarement besoin de construire tes classes entièrement à la carte. Tu auras peut être une configuration de Test avec des mocks, et une configuration de Prod avec des services réels, rarement une infinité de mix possibles qui te demandent la flexibilité d'un builder en pratique.