Existe-t-il des données concrètes sur la valeur de Inversion of Control ou de l'injection de dépendance?

Question

J'ai beaucoup lu sur IoC et DI, mais je ne suis pas vraiment convaincu que vous en tiriez beaucoup en les utilisant dans la plupart des situations.

Si vous écrivez du code nécessitant des composants enfichables, alors oui, je vois la valeur. Mais si vous ne l'êtes pas, alors je me demande si changer une dépendance d'une classe à une interface vous apporte vraiment quelque chose, autre que de taper plus.

Dans certains cas, je peux voir où IoC et DI aident à se moquer, mais si vous n'utilisez pas Mocking, ou TDD alors quelle est la valeur? Est-ce un cas de YAGNI?

Answer 1

Je doute que vous ayez des données concrètes à ce sujet, alors je vais ajouter quelques réflexions à ce sujet. Tout d'abord, vous n'utilisez pas DI (ou d'autres principes SOLID) car cela vous aide à faire TDD. C'est l'inverse, vous faites TDD parce que cela vous aide dans la conception - ce qui signifie généralement que vous obtenez du code qui suit ces principes. Discuter de la raison pour laquelle utiliser les interfaces est une question différente, voir: https://stackoverflow.com/questions/667139/what-is-the-purpose-of-interfaces.

Je suppose que vous êtes d'accord que le fait d'avoir vos classes fait beaucoup de choses différentes entraîne un code désordonné.Ainsi, je suppose que vous allez déjà pour SRP. Parce que vous avez différentes classes qui font des choses spécifiques, vous avez besoin d'un moyen de les relier. Si vous les reliez à l'intérieur des classes (c'est-à-dire les constructeurs), vous obtenez beaucoup de code qui utilise des versions spécifiques des classes. Cela signifie que les modifications apportées au système seront difficiles.

Vous allez avoir besoin de changer le système, c'est un fait du développement logiciel. Vous pouvez appeler YAGNI pour ne pas ajouter de fonctionnalités spécifiques, mais pas sur le fait que vous n'aurez pas besoin de changer le système. Dans mon cas, c'est quelque chose de vraiment important car je fais des sprints hebdomadaires. J'utilise un cadre DI dans lequel la configuration est faite par le code. Avec une très petite configuration de code, vous connectez beaucoup de relations différentes. Ainsi, lorsque vous supprimez la discussion sur l'interface par rapport aux classes concrètes, vous économisez réellement la frappe, pas l'inverse. Aussi pour les cas une classe concrète est sur le constructeur, elle l'accroche automatiquement (je n'ai pas à configurer) en construisant le reste des relations. Cela me permet également de contrôler la durée de vie de certains objets, en particulier je peux configurer un objet pour qu'il soit Singleton et qu'il ne passe qu'une seule instance tout le temps.

Notez également que l'utilisation de ces pratiques n'est pas plus lourde. Les utiliser pour les premières fois, est ce qui provoque les frais généraux (à cause du processus d'apprentissage + dans certains cas, le changement de mentalité).

Conclusion: vous n'aurez pas besoin de mettre tous ces appels constructeurs partout pour aller plus vite.

Answer 2

Les gains les plus significatifs de DI ne sont pas nécessairement dus à l'utilisation d'interfaces. Vous n'avez pas réellement besoin d'utiliser des interfaces pour avoir des effets bénéfiques de l'injection de dépendance. S'il n'y a qu'une seule implémentation, vous pouvez probablement l'injecter directement, et vous pouvez utiliser un mélange de classes et d'interfaces.

Vous êtes encore en train de perdre le couplage, et un bon nombre d'environnements de développement vous pouvez introduire cette interface avec quelques touches si nécessaire.

Données dures sur la valeur du couplage lâche Je ne peux pas donner, mais c'est une vision dans les manuels aussi longtemps que je me souvienne. Maintenant c'est réel.

Les frameworks DI vous offrent également des fonctionnalités assez étonnantes en matière de construction hiérarchique de grandes structures. Au lieu de chercher le cadre de DI le plus mince autour, je vous recommande de chercher un système complet. Moins n'est pas toujours plus, au moins quand il s'agit d'apprendre de nouvelles façons de programmer. Puis vous pouvez aller pour moins.

Answer 3

En dehors des tests, le couplage lâche en vaut la peine.

J'ai travaillé sur des composants pour un système Java embarqué, qui avait une configuration fixe d'objets après le démarrage (environ 50 objets différents).

Le premier composant était le code hérité sans injection de dépendance, et les sous-objets étaient créés partout. Maintenant, il est arrivé plusieurs fois que pour une modification, du code soit nécessaire pour parler à un objet qui n'était disponible que pour trois constructeurs. Alors que pouvez-vous faire, mais ajouter un autre paramètre au constructeur et le passer, ou même le stocker dans un champ pour le transmettre plus tard. À la longue, les choses sont devenues encore plus embrouillées qu'elles ne l'étaient déjà.

Le deuxième composant que j'ai développé à partir de zéro, et utilisé l'injection de dépendance (sans le savoir à ce moment). C'est-à-dire que j'avais une usine qui construisait tous les objets et injectait alors sur une base de besoin de savoir. Ajout d'une autre dépendance était facile, il suffit de l'ajouter à la fabrique et le constructeur d'objets (ou ajouter un setter pour éviter les boucles). Aucun code indépendant n'a besoin d'être touché.