Je comprends les avantages de l'injection de dépendance elle-même. Prenons le printemps par exemple. Je comprends également les avantages d'autres fonctionnalités de Spring comme AOP, des aides de différents types, etc. Je me demande simplement quels sont les avantages de la configuration XML tels que:
<bean id="Mary" class="foo.bar.Female">
<property name="age" value="23"/>
</bean>
<bean id="John" class="foo.bar.Male">
<property name="girlfriend" ref="Mary"/>
</bean>par rapport à l'ancien code java tel que:
Female mary = new Female();
mary.setAge(23);
Male john = new Male();
john.setGirlfriend(mary);qui est plus facile à déboguer, à vérifier le temps de compilation et peut être compris par quiconque ne connaît que java. Alors, quel est le but principal d'un framework d'injection de dépendances? (ou un morceau de code qui montre ses avantages.)
MISE À JOUR:
En cas de
IService myService;// ...
public void doSomething() {
myService.fetchData();
}Comment le framework IoC peut-il deviner quelle implémentation de myService je veux être injectée s'il y en a plus d'une? S'il n'y a qu'une seule implémentation d'une interface donnée et que je laisse le conteneur IoC décider automatiquement de l'utiliser, il sera cassé après l'apparition d'une deuxième implémentation. Et s'il n'y a intentionnellement qu'une seule implémentation possible d'une interface, vous n'avez pas besoin de l'injecter.
Ce serait vraiment intéressant de voir un petit morceau de configuration pour IoC qui montre ses avantages. J'utilise Spring depuis un moment et je ne peux pas fournir un tel exemple. Et je peux montrer des lignes simples qui démontrent les avantages de la mise en veille prolongée, du dwr et d'autres frameworks que j'utilise.
MISE À JOUR 2:
Je me rends compte que la configuration IoC peut être modifiée sans recompilation. Est-ce vraiment une si bonne idée? Je peux comprendre quand quelqu'un veut changer les informations d'identification de la base de données sans recompiler - il n'est peut-être pas développeur. Dans votre pratique, à quelle fréquence quelqu'un d'autre que le développeur modifie la configuration IoC? Je pense que pour les développeurs, il n'y a aucun effort pour recompiler cette classe particulière au lieu de changer la configuration. Et pour les non-développeurs, vous voudrez probablement lui rendre la vie plus facile et fournir un fichier de configuration plus simple.
MISE À JOUR 3:
Configuration externe du mappage entre les interfaces et leurs implémentations concrètes
Qu'est-ce qui est si bon pour le rendre extenal? Vous ne rendez pas tout votre code externe, alors que vous le pouvez certainement - placez-le simplement dans le fichier ClassName.java.txt, lisez et compilez manuellement à la volée - wow, vous avez évité de recompiler. Pourquoi éviter la compilation?!
Vous gagnez du temps de codage car vous fournissez des mappages de manière déclarative, pas dans un code procédural
Je comprends qu'une approche parfois déclarative fait gagner du temps. Par exemple, je déclare une seule fois un mappage entre une propriété de bean et une colonne de base de données et hibernate utilise ce mappage lors du chargement, de l'enregistrement, de la construction de SQL basé sur HSQL, etc. C'est là que fonctionne l'approche déclarative. Dans le cas de Spring (dans mon exemple), la déclaration avait plus de lignes et avait la même expressivité que le code correspondant. S'il y a un exemple où une telle déclaration est plus courte que le code - je voudrais le voir.
Le principe d'inversion du contrôle permet des tests unitaires faciles car vous pouvez remplacer les implémentations réelles par de fausses (comme le remplacement d'une base de données SQL par une base de données en mémoire)
Je comprends l'inversion des avantages du contrôle (je préfère appeler le modèle de conception discuté ici comme injection de dépendance, car l'IoC est plus général - il existe de nombreux types de contrôle et nous n'en inversons qu'un seul - le contrôle de l'initialisation). Je demandais pourquoi quelqu'un a jamais besoin d'autre chose qu'un langage de programmation pour cela. Je peux certainement remplacer de vraies implémentations par de fausses en utilisant du code. Et ce code exprimera la même chose que la configuration - il initialisera simplement les champs avec de fausses valeurs.
mary = new FakeFemale();Je comprends les avantages de la DI. Je ne comprends pas quels avantages sont ajoutés par la configuration XML externe par rapport à la configuration de code qui fait de même. Je ne pense pas que la compilation devrait être évitée - je compile tous les jours et je suis toujours en vie. Je pense que la configuration de DI est un mauvais exemple d'approche déclarative. La déclaration peut être utile si elle est déclarée une fois ET est utilisée plusieurs fois de différentes manières - comme hibernate cfg, où le mappage entre la propriété du bean et la colonne DB est utilisé pour enregistrer, charger, créer des requêtes de recherche, etc. La configuration Spring DI peut être facilement traduite en configurer le code, comme au début de cette question, n'est-ce pas? Et il n'est utilisé que pour l'initialisation du bean, n'est-ce pas? Ce qui veut dire qu'une approche déclarative n'ajoute rien ici, n'est-ce pas?
Lorsque je déclare le mappage d'hibernation, je donne simplement quelques informations à l'hibernation, et cela fonctionne en fonction de cela - je ne lui dis pas quoi faire. En cas de printemps, ma déclaration dit exactement au printemps ce qu'il faut faire - alors pourquoi le déclarer, pourquoi ne pas le faire?
DERNIÈRE MISE À JOUR: Les
gars, beaucoup de réponses me parlent de l'injection de dépendance, ce que JE SAIS EST BON. La question concerne le but de la configuration DI au lieu de l'initialisation du code - j'ai tendance à penser que l'initialisation du code est plus courte et plus claire. La seule réponse que j'ai eue jusqu'ici à ma question, c'est qu'elle évite la recompilation, lorsque la configuration change. Je suppose que je devrais poster une autre question, car c'est un grand secret pour moi, pourquoi la compilation devrait être évitée dans ce cas.