Pourquoi avons-nous besoin de cadres pour l'injection de dépendance? [fermé]

42

J'ai lu davantage sur le principe d'inversion de contrôle et l'injection de dépendance comme une mise en œuvre de celui-ci et je suis à peu près sûr de le comprendre.

Il semble en gros dire «ne déclarez pas les instanciations de vos membres de classe dans la classe». Plutôt que les instanciations devraient être passées et assignées par le constructeur; "injecté" dans la classe à partir d'une source extérieure.

Si c'est aussi simple que cela semble être le cas, pourquoi avons-nous besoin de cadres tels que Spring ou guice qui implémentent cela avec des annotations? Est-ce que je manque quelque chose de fondamental ici? J'ai vraiment du mal à comprendre l'utilisation des frameworks d'injection de dépendance.

Edit: En ce qui concerne les doublons possibles, je pense que ma question est plus unique car elle concerne les cadres de DI en général, pas seulement le printemps. Spring n’est pas simplement un cadre d’ID, il existe donc de nombreuses raisons pour lesquelles une personne voudrait utiliser Spring qui n’est pas liée à un ID.

dependency-injection spring inversion-of-control google-guice Timsworth
la source
Duplication possible de Que fait le framework Spring? Devrais-je l'utiliser? Pourquoi ou pourquoi pas?
moucher
11
Ils sont utiles pour décaler les erreurs dans l'exécution au lieu du temps de compilation.
Den
1
@den Pourquoi voudrions-nous faire cela? Cela semble violer les échecs rapides
CET UTILISATEUR A BESOIN D'AIDE

Réponses:

26

Nous n'avons pas besoin des cadres. Il est tout à fait possible d'implémenter l'injection de dépendance manuellement, même pour un projet relativement volumineux.

En revanche, utiliser un framework facilite les choses, en particulier celles basées sur des annotations ou la détection automatique des dépendances, car cela simplifie le processus: si je décide d’avoir besoin d’une nouvelle dépendance dans une classe, il suffit d’ajouter au constructeur (ou déclarer un installateur) et l'objet est injecté - je n'ai pas besoin de changer le code d'instanciation.

De plus, les frameworks contiennent souvent d'autres fonctionnalités utiles. Spring, par exemple, contient un cadre utile pour la programmation orientée aspect, y compris la démarcation déclarative des transactions (ce qui est extrêmement pratique) et diverses implémentations d’adaptateur qui facilitent l’intégration de nombreuses bibliothèques tierces.

Jules
la source
8
Mettre le doigt dessus. Nous n'avons pas besoin d'eux. Ils facilitent simplement la vie pour les grands projets. Honnêtement, je trouve que les cadres sont plus compliqués que pour des projets plus petits. J'encourage OP à ne pas confondre l'injection de dépendance avec les cadres qui la prennent en charge.
RubberDuck
1
bien dit. Et pourquoi réinventer la roue quand quelqu'un d'autre en a déjà fabriqué une qui est belle et ronde?
Jwenting
Exactement ça. Sauf que je n'ai pas besoin de changer de code d'instanciation - bien sûr, il n'y a pas de code d'instanciation ;-)
Mathieu Guindon
Il semble que vos bibliothèques de DI piquent. Les bons peuvent deviner la classe à instancier en utilisant la réflexion.
Florian Margaine
2
quiconque utilise la réflexion pour le traitement de l'exécution ne le fait pas correctement. La réflexion est l’une de ces technologies qui ne veut pas dire que ce soit juste parce que vous pouvez faire quelque chose.
gbjbaanb
12

  1. Pourquoi avons-nous besoin de DI (Dependency Injection)?

    Le mécanisme DI sépare la production d'objets de la consommation d'objets. Les dépendances dont un objet a besoin sont livrées de manière transparente de l'extérieur. L'avantage du mécanisme est clair: vous pouvez à tout moment échanger les dépendances, par exemple en utilisant un objet Null à des fins de test.

  2. Comment est-il fait?

    Il y a plusieurs façons d'atteindre l'objectif:

    • Injection de dépendances via l'injection de constructeur
    • Injection par getter / setter
    • Interface d'Injection

  3. Avons-nous besoin de cadres de DI?

    Non pas du tout. Vous pouvez simplement passer toutes les instances à d'autres objets manuellement. Si vous avez une petite application, il n'y a pas besoin d'un conteneur à ressort.

    Mais d'autre part, les frameworks vous donnent un coup de main pour gérer des objets:

    • Ils vous aident à établir des relations d'objet complexes. Vous devez écrire aucun code standard pour générer des instances et les transmettre aux objets appropriés

    • Ils vous aident à contrôler le moment où un objet est créé: vous pouvez créer des instances lors du démarrage de l'application, mais dans certains cas, une création paresseuse, uniquement lorsque cela est nécessaire, est préférable.

    • Ils vous aident à contrôler le nombre d' instances créées: une par durée de vie de l'application ou une par requête (dans le cas d'une programmation Web).

Si votre projet a une taille appropriée, si vous ressentez le besoin d'écrire moins de code standard, il est tout à fait judicieux d'utiliser un cadre (DI). Il y a plus d'avantages que d'inconvénients.

Thomas Junk
la source
2
Vous pouvez utiliser des bibliothèques DI sans utiliser de cadre.
Florian Margaine
5

Avec le printemps, c'est surtout une question de commodité.

Si vous avez une classe TopLevelqui est une classe MiddleLevelqui construit une classe LowLevelet que vous vous rendez compte que vous avez besoin d'un nouveau paramètre de constructeur LowLevel, vous devez également l'ajouter à TopLevel, et à MiddleLevel, simplement, de sorte que la valeur soit disponible au moment MiddleLevelde la construction LowLevel. afin qu'il puisse être passé à son constructeur. Avec le printemps, vous ajoutez simplement une annotation.

De plus, avec spring, il est possible de définir les dépendances dans un fichier de configuration externe au lieu de xml, ce qui vous permet supposément de générer un nouveau système avec un câblage totalement différent "sans changer de code". (IMHO cela est complètement mal dirigé, car la modification de XML n'est pas très différente de la modification de code, et en réalité, le code a généralement une vérification d'erreur et de vérification de type bien meilleure que celle de XML.)

Une autre chose est que beaucoup de gens ont peur des constructeurs; ils ne les comprennent pas, ils ne les aiment pas, ils préfèrent ne pas les utiliser.

Mike Nakis
la source
3
Plutôt d'accord, surtout avec la remarque XML. IMHO, avoir peur des constructeurs est probablement une mauvaise raison d'utiliser un framework DI.
Robert Harvey
2
IMHO, avoir peur des constructeurs est une bonne raison de rester en dehors de la programmation. C -: =
Mike Nakis
5
Mais en quoi est-ce un avantage par rapport à une usine (statique ou autre)? (Ce qui a l'avantage d'être une option que vous pouvez utiliser comme il convient alors que le printemps semble être un tout ou rien)
Richard Tingle
@RichardTingle Spring peut représenter un avantage principalement en raison de toutes les tâches qu'il réalise, à part le DI, car vous pouvez évidemment réaliser le DI de nombreuses autres façons, les usines statiques en étant un. (Un des moins cool, mais quand même.) Mais la question qui se pose est de savoir s’il est nécessaire d’utiliser le printemps pour atteindre le DI, et c’est ce que j’essayais de répondre: au fond, ce n’est pas nécessaire, mais simplement pour plus de commodité. .
Mike Nakis
Ceci est un exemple de ce que DI n'est pas. ´TopLevel` ne devrait pas créer MiddleLevel, mais devrait le recevoir lors de la construction TopLevelen tant qu'argument du constructeur. De même MiddleLeveldevrait recevoir un LowLeveldans son constructeur.
Clairière
1

Il y a quelques années, j'ai écrit un programme permettant de surveiller les pages Web, les portlets Web, voire certaines tables de base de données, dans une entreprise pour laquelle je travaillais auparavant. Je voulais qu'il soit suffisamment flexible pour que l'utilisateur puisse spécifier quels moniteurs s'exécuteraient et avec quels paramètres (URL, logins, critères de réussite, etc.). Je l'ai donc écrit pour lire à partir d'un fichier XML et utiliser la réflexion Java pour instancier les classes spécifiées, ainsi que des méthodes de définition pour définir les paramètres spécifiés.

Plus tard, j'ai découvert que le printemps ferait la même chose pour vous, et bien plus encore.

Donc dans mon cas j'ai trouvé que

  1. L'utilisation d'un framework d'injection de dépendance permet de rendre le programme flexible et facilite la spécification de son fonctionnement (dans des paramètres bien définis, bien sûr).

  2. L'utilisation d'un cadre de DI tiers vous évite de réinventer la roue.

Paul J Abernathy
la source
4
Pourriez-vous expliquer davantage pourquoi la définition de la classe concrète à utiliser est préférable dans un fichier xml plutôt que dans un fichier java. C'est la chose que je n'ai jamais comprise.
Richard Tingle
1
Ce n'est pas une solution miracle, mais l'un des avantages de l'utilisation des fichiers de configuration est qu'ils sont, du moins en théorie, plus faciles à modifier que le code. De plus, ils peuvent être modifiés par un utilisateur qui exécute votre programme mais n'a pas accès à votre code source. Dans l'exemple que j'ai donné de mon programme d'injection de dépendance brute, je modifiais parfois le fichier de configuration XML afin de pouvoir modifier le mode d'exécution du programme, même si c'était moi qui l'avais écrit. Si vous n'avez pas besoin de la configurabilité externe, il peut être plus facile de le faire avec du code. J'ai eu un autre travail où nous avons fait toute l'ID dans le code et cela a bien fonctionné.
Paul J Abernathy