Discussion :

[M_Makia]

Bonjour à toutes et à tous.

J'utilise l'injection de dépendances dans la majorité de mes projets, cependant je m’interroge sur son utilité.
La question n'est pas de définir à quoi sert l'injection de dépendances, mais pourquoi et quand l'utiliser.
Pour ma part je n'ai jamais eu à revenir sur un projet x mois ou années plus tard et "profiter" de l'injection de dépendances.

Je souhaiterais savoir si vous utilisez l'injection de dépendances dans la majorité de vos projets ?

Si non pourquoi ?

Si oui, avez vous déjà "profiter" pleinement de l'injection de dépendances sur vos projets ?

D’après vous à partir de quel moment faut-il consacrer du temps pour la mise en place de l'injection de dépendances ?

Pensez-vous que c'est un bonne pratique et que la question ne se pose pas ?

[worm83]

Bonjour,
Alors pour répondre à tes questions :

- Non je n'utilise pas toujours un framework d'injection dans mes projets, mais je design TOUJOURS mes classes et mes projets pour pourvoir le faire (ou que ceux qui maintiendrons le mettent en place sans douleurs au cas ou le besoin évolue).

- Oui j'ai déjà pleinement profité de l'IOC dans mes projets, surtout lorsque tu t'es fabriqué des classes que tu réutilise dans énormément de projet, et que tu t'en ressert.

J'ai un exemple récent, j'avais fait un moteur de serveur de log, et je voulais être indépendant de la BDD, grace à l'IOC je n'ai eu que le business de ma BDD à écrire (car le client avait une définition métier différente de ce qu'est un log), c'est à dire 2 jours de boulots alors que pour tout refaire, ou adapter, si je n'avais pas pensé "ioc", j'aurais mis peut être 5 fois plus de temps (voir plus).

- Personnellement je ne passe de temps spécialement à mettre en place l'IOC, je le fait "naturellement" lors du design de mes classes (ne serais-ce que pour faciliter la mise en place des Tests). Quand à l'utilisation d'un injecteur à proprement parlé je ne l'utilise PAS lorsque je sais que les moyens d'échange entre les classes ne va pas changer, mais comme mes classes sont pensées pour, sa mise en place sera facile.
Mais dans la pratique, vu que la plupart du temps on met place des tests unitaires ou d'intégrations, il y a toujours un endroit du projet ou tu utilise un Framework d'injection pour te permettre de stubber ou mocker.

Selon mon humble avis, mettre en place de l'abstraction et de la modularité dans un projet est une bonne pratique dont l'utilité ne se pose pas. Mais parfois le besoin, ou la petite taille du projet ne l'impose pas (et peut même faire perdre du temps), ce n'est pas pour cela par exemple si le projet est petit que l'on met tout le code dans une même fonction, quoiqu'il arrive on découple et on mutualise, je crois qu'il en est de même pour l'IOC.

[M_Makia]

Merci pour ta réponse.

Quelle librairie utilises tu pour faire l'injection de dépendance ?

[worm83]

J'utilise majoritairement Unity, mais il m'est arrivé d'utiliser MEF, castle ou ninject.
Cela dépend si j'ai besoin de plus de fonctionnalité (AOP, introspection, plugin) de perf (tissage, proxy ect...).

[Lakhdr]

Soit le D de SOLID simplement

[DonQuiche]

J'ai déjà eu à travailler avec MEF pour créer des plugins mais je n'ai jamais de moi-même introduit l'usage de ce type de frameworks dans mes développements.

Pour moi ils ne devraient être utilisées que lorsqu'il est impossible de fournir d'une façon plus directe la concrétisation (le service) à utiliser. Je préfère cent fois passer une interface à un constructeur que d'avoir toute une plomberie impliquant des identifiants à base de chaînes ou de GUID, de l'introspection lente et inutilisable dans certaines conditions (ou du tissage qui ralentit la compilation), des problèmes de testabilité, etc. Autrement dit ces frameworks devraient à mon sens être réservés aux cas où le service à utiliser sera déterminé à l'exécution selon les plugins découverts, voire selon un fichier de configuration.

A mon sens l'usage banalisé de ce type de framework relève du YAGNI (you ain't gonna need it).

Soit le D de SOLID simplement

Non, ça va beaucoup plus loin (trop loin). Il faut bien distinguer les choses :

Le DIP (dependency inversion principle) promeut le fait d'abstraire les détails afin que du code haut-niveau ne manipule pas des éléments de bas niveau. Le DPI porte donc sur l'abstraction de niveaux de détails, uniquement aux frontières entre code haut niveau et bas niveau, pas nécessairement via des types abstraits (une façade ou un bon usage de la visibilité des membres peuvent suffire), et sans aucun lien avec l'injection dynamique par du code tierce-partie ou par les utilisateurs.

Au-delà de ça certains choisissent en plus d'utiliser des abstractions à tout moment, à tout niveau. C'est souvent guidé soit par une lecture aveugle d'indicateurs comme la complexité cyclomatique, soit par un souci de testabilité. Ça n'a souvent rien à voir avec le DIP (abstractions de types et abstractions logiques sont deux choses distinctes) et malheureusement cela relève trop souvent du YAGNI et a tendance à créer l'équivalent moderne du code spaghetti : au lieu d'un seul clic sur "go to definition" pour aller vers le code intéressant, nous serons d'abord amenés vers une interface, puis il faudra chercher les mises en œuvre de l’interface, aller vers cette mise en œuvre et finalement rechercher la méthode correspondante. Tout ça au cas où un jour on aurait besoin de faire des changements ou du recyclage qui de toute façon n'auraient pas été beaucoup plus compliqués à réaliser sans cela (voire pas du tout : abstraire ne veut pas dire anticiper les besoins futurs) !

Enfin encore au-delà certains choisissent de toujours supporter des injections dynamiques de code via des frameworks dédiés même lorsque le besoin n'existe pas. J'ai déjà expliqué pourquoi à mon sens cela relève souvent du YAGNI et peut constituer une mauvaise pratique.

[Lakhdr]

Salut DonQuich!
Je suis pas sur d'avoir compris ce que vous avez voulu dire ! Juste pour le debat je rajoute ceci :

Machiavel disait la fin justifie les moyens , donc tout depend de ce que vous voulez faire si pour une petite application et que vous vous amusez a faire de l'injection de dépendances, ca serait dommage vous perdez votre temps et c est du YAGNI et pas du KISS
Maintenant si vous construisez une grande application une tres grande application la Vous allez peut etre me dire il faut diviser pour regner diviser l application en plusieurs bouts que a un moment donné vous avez besoin de faire de l assemblage donc certains proposent de faire de l injection de dependances .


SI parceque le F12 (go to def ) ne trouve pas l implemenation d un contrat dans certaines librairies de DI , C est pas une raison pour les rejeter je crois .
A mon Avis sans la DI dans une grande application vous aller produire du spaghetti du merguez etc ... et vous allez accroître les cyclotomiques en conséquence la probabilité d bug et aussi reduire la maintenabilité l votre code deviendra moins évolutif .

Merci