Comment l'injection de dépendances ne déplace-t-elle pas simplement la complexité dans une classe distincte?

J'ai cherché à utiliser le framework Typhoon pour l'injection de dépendances cette semaine. J'ai l'impression que séparer la construction d'objets est bénéfique pour remplacer des composants arbitraires par des simulateurs lors des tests unitaires, et jusqu'à présent, j'ai vu des avantages de cela seul.

Mais je ne peux pas m'empêcher de penser que là où avant j'avais une classe de contrôleur de vue énorme qui avait des dizaines d'importations d'en-tête, j'ai maintenant une classe d'usine énorme qui a des dizaines d'importations d'en-tête. Suis-je censé éviter d'avoir une classe d'usine massive?

dependency-injection

— Victor
source

Dans une décennie, je m'attends à ce que DI prenne la tête de Singleton, mais cette fois pour de bonnes raisons. Il a de bonnes utilisations mais je suggère d'être très prudent en évaluant l'impact.

— Balog Pal

Je ne pense pas que l'injection de dépendances soit un moyen de réduire la complexité mais un moyen d'éviter les dépendances implicites (utilisation de symboles globaux / variables libres) au profit de dépendances explicites (utiliser des paramètres explicites / variables liées). Donc, la complexité est toujours là, mais vous êtes obligé de la gérer parce que vous la rendez explicite dans vos signatures de méthode / constructeur.

— Giorgio

Notez que pratiquement n'importe quel système d'organisation du code peut être décrit comme «déplaçant simplement la complexité ailleurs». Il ne s'agit pas tant de supprimer la complexité que de l'organiser de la manière la plus logique et la plus utile.

Si vous devez importer 50 en-têtes, vous devez le faire quelque part. DI vous aide à tester plus facilement votre code.

— BЈовић

Donc, dites-vous que maintenant votre contrôleur se concentre sur le contrôle et que votre usine d'importation d'en-tête se concentre sur les importations d'en-tête? Comment cela peut-il être une mauvaise chose, que vous utilisiez ou non un framework DI?

— pdr

Réponses:

L'injection de dépendances aide simplement à définir comment un objet connaît un autre objet dépendant. Cela ne vous aidera pas à réduire la complexité globale du système. Si vous avez eu besoin de dizaines d'importations avant DI, vous aurez toujours besoin de dizaines d'importations après. La différence est que ces importations se feront dans un emplacement (classe) plus logique (usine, constructeur, etc.).

En permettant aux dépendances d'être fournies via un constructeur ou une méthode, vous vous donnez la flexibilité de fournir un objet dépendant différent, mais toujours valide, à votre classe et augmentez la cohésion de cette classe en supprimant les problèmes.

Il existe plusieurs principes similaires et souvent utilisés ensemble: l'injection de dépendance (DI), l'inversion de contrôle (IoC) et le principe d'inversion de dépendance (DIP)

De cet article http://martinfowler.com/articles/dipInTheWild.html

DI concerne le câblage, l'IoC concerne la direction et le DIP concerne la forme

— Seth M.
source

+1, pour le dernier devis. C'est la meilleure clarification de ces 3 concepts que les gens comprennent souvent mal.

— haylem

L'article lié ci-dessus est vraiment exceptionnel. Une explication suffisamment profonde et très claire.

— DemetriKots

L'injection de dépendance ne réduit pas la complexité, mais elle augmente la maniabilité par la séparation des préoccupations et le couplage réduit.

Mais je ne peux pas m'empêcher de penser que là où avant j'avais une classe de contrôleur de vue énorme qui avait des dizaines d'importations d'en-tête, j'ai maintenant une classe d'usine énorme qui a des dizaines d'importations d'en-tête. Suis-je censé éviter d'avoir une classe d'usine massive?

Vous êtes censé éviter les cours "énormes", point final. Supposons donc que vous divisiez le contrôleur de vue en classes plus petites et plus faciles à gérer. Désormais, tous sont responsables de s'emparer de leurs dépendances. DI vous aide à déplacer cette gestion de la dépendance de toutes ces classes dans une classe usine / configuration qui est seule responsable de la gestion de la dépendance - voir responsabilité unique principe. Et bien qu'il soit certainement beaucoup moins "gigantesque" que le contrôleur de vue d'origine, s'il devient trop grand, vous avez toujours la possibilité de le diviser en classes de gestion des dépendances plus petites qui sont responsables des différentes parties de l'application.

— Michael Borgwardt
source

Dans les mots du profane:

L'injection de dépendance déplace la complexité là où elle nuit le moins.

EDIT pour @gnat: DI ne fait pas que déplacer la complexité vers une classe distincte, elle la déplace là où elle cause le moins de dommages.

— Tulains Córdova
source

comment cela répond-il à la question posée?

— moucher

@gnat a ajouté une modification, ma réponse explique à mon avis comment DI ne fait pas que déplacer la complexité dans une classe distincte.

— Tulains Córdova