Discussion :

[violonsdAutomne]

Bonjour,

Je me pose la question du bien-fondé de l'annotation @Autowired.

Considérons la situation suivante :

- une interface Toto
- une classe TotoImpl implémentant l'interface Toto
- une classe X déclarant un attribut attr de type Toto

Avant Spring, on mettait quelque part dans le code de X la ligne de code suivante :
attr = new TotoImpl()

Les plus malins créaient une factory de Toto permettant de découpler X de TotoImpl. Néanmoins, l'appel au constructeur de TotoImpl devait quand même apparaitre dans le code (de la factory).

Avec Spring, le découplage est total :
- on écrit dans un fichier de configuration xml :
<bean id="toto" class="TotoImpl"/>
<bean id="x" class="X"/> <property name="attr" ref="toto"/> </bean>
- et il n'y a plus aucun appel au constructeur de TotoImpl dans le code java.

Maintenant, si je crée une classe TotoImplBis qui implémente aussi Toto. J'ai juste à changer de fichier xml pour faire en sorte que attr pointe vers une instance de ma nouvelle classe.
Là, je vois bien l'intérêt de la chose : le code de Toto et de X est parfaitement réutilisable (même si je n'ai pas les sources).

Avec Spring 2.5, on me propose d'utiliser des annotations.
- J'annote donc les classes TotoImpl et X avec @Component
- J'annote attr avec @Autowired

J'ai cru comprendre que l'intérêt de telles annotations était d'alléger les fichiers xml. Je comprends bien que je n'ai plus besoin de définir mes beans explicitement et que Spring va faire tout le travail pour moi (j'ai juste à fournir une petite formule magique dans le fichier xml).
Mais, si je reprends mon idée de créer une classe TotoImplBis (évidemment annotée avec @Component), Spring me signale, à juste titre, qu'il ne sait pas quel bean associer à attr.

1/ J'ai donc perdu la réutilisabilité du code que Spring m'avait fait gagner dans un premier temps.
2/ Si de telles annotations ne sont utiles que lorsqu'il n'y a qu'une seule implémentation pour une interface donnée, à quoi bon découpler les choses. Autant revenir à la situation initiale et remettre un new TotoImpl() dans le code de X.

J'espère que mes explications ne sont pas trop embrouillées, et si quelqu'un veut bien éclairer ma lanterne en me disant ce que l'on gagne vraiment avec ces annotations, je lui en serait reconnaissant.

[fr1man]

Dans le cas de plusieurs implémentations possibles, tu peux utiliser l'annotation @Qualifier pour préciser celle que tu veux utiliser.

[violonsdAutomne]

Oui, je sais. Mais ça ne répond pas vraiment à ma question.
Si je ne dispose que du code exécutable de Toto, TotoImpl et X, le seul moyen que j'ai d'utiliser une autre implémentation de Toto est de réécrire un fichier xml avec des beans. Et du coup, les annotations deviennent inutiles.

Et pire que ça, si je dois conserver le component-scan dans un fichier de configuration parce que d'autres parties du code en ont besoin, et bien, je ne peux plus m'en sortir.

Mais, peut-être que je fais fausse route ?
D'autres avis?

[HerQuLe]

Oui, je sais. Mais ça ne répond pas vraiment à ma question.
Si je ne dispose que du code exécutable de Toto, TotoImpl et X, le seul moyen que j'ai d'utiliser une autre implémentation de Toto est de réécrire un fichier xml avec des beans. Et du coup, les annotations deviennent inutiles.

Et pire que ça, si je dois conserver le component-scan dans un fichier de configuration parce que d'autres parties du code en ont besoin, et bien, je ne peux plus m'en sortir.

Mais, peut-être que je fais fausse route ?
D'autres avis?

Tu as tout a fait raison

Voir cette question SO: http://stackoverflow.com/questions/4...it-goal-of-ioc

Le mieux est de repasser en mode XML lorsque tu as des implémentations différentes entre vrai appli et appli de test par exemple.

Ou alors tu utilises une FactoryBean qui utilise le profile Spring pour savoir quelle implémentation fournir (3.0 ou 3.1 je crois par contre).

Je suis pas trop fan du @Qualifier car la dépendance est au final tout autant hardcodée

[ruscov]

Oui, je sais. Mais ça ne répond pas vraiment à ma question.
Si je ne dispose que du code exécutable de Toto, TotoImpl et X, le seul moyen que j'ai d'utiliser une autre implémentation de Toto est de réécrire un fichier xml avec des beans. Et du coup, les annotations deviennent inutiles.

Pas si tu utilise @Qualifier comme l'a dit fr1man

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
@Autowired
@Qualifier("tonImpl")

Si tu n'as qu'une seule implémentation, tu n'as pas besoin du tag Qualifier, Spring sait quelle classe intancié.
Le but des annotations c'est de se passer du XML.

L'avantage aussi de ces tags, c'est que c'est Spring qui gère le cycle de vie de l'objet.

Autant revenir à la situation initiale et remettre un new TotoImpl() dans le code de X.

Autant pas utiliser Spring alors...

[andry.aime]

Bonjour,

Il est conseillé d'utiliser @Resource(name="machin") par rapport à @Autowired @Qualifier("machin").

A+.