Je développe dans Spring Boot depuis un peu plus dun an mais je nai pas encore compris les avantages de lutilisation dun constructeur Autowired et je me demandais si quelquun pouvait expliquez-moi cela et ce qui serait considéré comme la meilleure pratique.
Disons que jai un bean comme suit
@Component public class MyBean { void doSomeStuff() { } } Et jai un service qui a une dépendance sur ce bean
@Service public class MyServiceImpl implements MyService { private MyBean myBean; } Pour moi, le moyen le plus simple dinjecter la dépendance dans cette classe serait simplement dannoter la variable avec @Autowired
@Service public class MyServiceImpl implements MyService { @Autowired private MyBean myBean; } Mais il y a dautres endroits en ligne (et aussi dautres développeurs de mon équipe) qui préfèrent quelque chose comme cette approche:
@Service public class MyServiceImpl implements MyService { private MyBean myBean; @Autowired public MyServiceImpl(MyBean myBean) { this.myBean = myBean; } } Pour moi, utiliser un constructeur comme celui-ci est simplement du code redondant. Le câblage automatique du bean est beaucoup plus simple et direct que ce qui me semble être du code standard.
Commentaires
Réponse
Vous utilisez un constructeur réel pour les mêmes raisons que vous utilisez des getters et des setters publics au lieu de rendre publiques des variables privées.
Quelques exemples concrets: les téléphones portables ne sont pas autorisés dans des emplacements physiques sécurisés et sensibles aux informations. Toute communication avec cet emplacement sécurisé doit avoir lieu via un protocole de communication sécurisé, contrôlé et crypté, et non subrepticement par un canal de communication non contrôlé et non contrôlé.
Lors dun concert, vous ne permettez pas aux gens de jeter des choses par-dessus la clôture à quelquun qui est déjà dans le stade. Tout ce qui entre ou sort doit passer par une porte.
Si cest tout ce quil y a dans votre exemple de code, cela ressemble à un passe-partout inutilement détaillé. Mais souvent, nous faisons dautres choses dans le constructeur en plus de définir variables privées, comme la validation. Dans de nombreux langages de programmation, changer la façon dont vous procédez après coup est un changement de rupture binaire, donc fournir le constructeur à lavance peut être une étape judicieuse.
Enfin, la classe devrait être capable de fonctionner indépendamment de linjection de dépendances. Si vous mettez une annotation sur un membre privé, mais que vous ne parvenez pas à inclure un constructeur , vous « avez essentiellement étroitement lié cette classe au conteneur DI, et la classe ne fonctionnera pas sans lui.
Commentaires
- " Lors dun concert, vous ' t autorisez les gens à jeter des objets par-dessus la clôture à quelquun qui ' s déjà dans le stadiu m. Tout ce qui entre ou sort doit passer par une porte. " Mais je ne ' voir comment l’utilisation d’un constructeur rend le câblage automatique plus sûr? Sil ny avait pas dexigences de constructeur (comme la validation), alors serait-il avantageux dutiliser un constructeur?
- Vous permettez dajouter une validation plus tard sans casser la compatibilité binaire.
- Aussi , notez que les membres privés doivent vraiment rester privés. Que ' est un peu lintérêt davoir des membres privés.
- Tout lintérêt est de permettre des bonnes pratiques de conception compatibles avec @Autowire. Avoir des constructeurs est la chose la plus naturelle en POO. Le contraire (ce que vous appelez simple et direct) est un peu effrayant. Il ny a pas de réels avantages à supprimer des constructeurs, il ny a ' aucune simplicité. Les constructeurs sont parmi les méthodes les plus simples en POO.En soi, ils ont généralement très peu de complexité qui vaut la peine dimplémenter la magie de Spring IoC
- Pour ce que cela vaut ', Java a tendance à être un langage très verbeux de toute façon. Si vous ' cherchez à apprivoiser une partie de cette verbosité, il est peu probable que lélimination des constructeurs nuise.
To me, using a constructor like that is simply redundant code. Autowiring the bean is much simpler and straightforward than what appears to me to be boilerplate code.et nêtes-vous pas préoccupé par la magie dinjecter un bean dans une variable instace qui est privée et na pas de setter? Ne vous inquiétez-vous pas de lénorme dette technique que cela génère pour vous, vos collègues? Ne vous souciez-vous pas de trop relayer le paradigme magique de Spring ' au lieu des bonnes pratiques de conception?