Introduction à l'injection de dépendances

a marqué ce sujet comme résolu.

Oui oui pour l'utilité t'en fais pas, j'ai utilisé Spring pendant des années, je suis en train de ré-implémenter Jersey sur Vert.x, j'utilise aussi des services, modules, contrôleurs AngularJS donc oui le cas que tu décris ne m'est pas du tout inconnu ^^

Ce que je veux dire c'est que soit :

  • le cours s'adresse à des gens qui connaissent l'injection de dépendance et à ce compte-là il vaut mieux se cantonner à décrire les annotations et ce qu'elles font (si je devais écrire un truc sur Spring, je dirais que tes managers sont des @Component et que dans chacun on retrouve des DAOs @Autowired, et je pourrais presque m'arrêter là)

  • le cours s'adresse à des débutants complets, et à ce compte là l'exemple ne suffit pas, puisque dans ce cas l'injection de dépendance n'a quasiment aucun intérêt.

L'exemple d'AngularJS est frappant d'ailleurs. Tu as un service qui fait des requêtes APIs, tu vas t'en servir dans presque tous tes contrôleurs. Et t'as pas envie d'aller le chercher à chaque fois. T'as envie de déclarer ta dépendance et que le framework s'en occupe.

Ton exemple de managers et DAOs et l'exemple parfait d'injection de dépendances et du coup tu le dis toi-même "tous mes DAOs sont injectables dans n'importe quel manager" => OUI et je pense que c'est ça qu'il est essentiel de faire comprendre à un débutant, sans quoi il risque de ne pas comprendre l'intérêt.

Je me mets à la place d'un débutant : pour initialiser une propriété intrinsèque d'un objet, autant passer par le constructeur. Par contre pour injecter un objet qui a un cycle de vie en dehors de mon objet alors là oui.

(ça revient à l'histoire du pizzaiolo qui bosse dans plein de pizzeria à la fois, peut-être qu'en parlant des recettes ça serait plus illustratif d'ailleurs).

+0 -0

J'aime toujours beaucoup tes interventions Javier, constructives et ça amène toujours à réflexion.

le cours s'adresse à des débutants complets, et à ce compte là l'exemple ne suffit pas, puisque dans ce cas l'injection de dépendance n'a quasiment aucun intérêt.

Tout à fait et je me rends compte que mes exemples ne sont pas suffisants en l'état pour amener le lecteur à une utilisation concrète de l'injection de dépendances. Peut-être que des exemples dans des cas concrets (sans tout le bruit de l'implémentation derrière) amènera plus le lecteur d'avantage dans cette utilisation concrète.

L'exemple d'AngularJS est frappant d'ailleurs. Tu as un service qui fait des requêtes APIs, tu vas t'en servir dans presque tous tes contrôleurs. Et t'as pas envie d'aller le chercher à chaque fois. T'as envie de déclarer ta dépendance et que le framework s'en occupe.

C'est exactement la même chose avec l'injection de dépendances avec Guice ou Dagger. Tu me permets de te piquer la phrase et de la reformuler dans le tutoriel ? ^^

Bien, j'ai été pas mal occupé mais j'ai pris un peu de temps pour repenser mes exemples. J'aimerais avoir vos avis avant de changer tous mes exemples.

Les choses que j'aimerais expliqué ne changent pas : @Inject (sur constructeurs et attributs), @Named, les annotations personnalisées et l'usage des Provider.

Pour illustrer ces concepts, j'imagine la chose suivante :

  • PizzaManager vers PizzaDao et IngredientDao illustreront @Inject.
  • PizzaManager vers Pizzaillustrera Provider.
  • PaymentManager vers PayPal et CreditCard illustreront @Named et les annotations personnalisées.

Qu'est ce que vous en pensez ?

J'ai mis à jour la version en bêta (comme en témoigne le message automatique précédent) suivant les retours que vous m'avez fait. Les exemples ne correspondent pas tout à fait à mon précédent diagramme mais ils s'en rapprochent dans l'idée.

N'hésitez pas à me faire des retours rapidement si vous le jugez utile, j'ai déjà envoyé le tutoriel en validation. Mais pour moi, je le trouve maintenant nettement mieux et ça, c'est beaucoup grâce à vous ! Merci bien. :)

Ce sujet est verrouillé.