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

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.

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.

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.

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.

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.