web-dev-qa-db-fra.com

Les haricots de printemps sont-ils déclarés statiques comme un mauvais choix de conception?

La question est assez simple, je vais essayer d'expliquer pourquoi je veux des explications.

(Tout cela est mon junior d'un an et demi Java avis du développeur, qui peut être plus que incomplet. C'est pourquoi je pose la question là-bas).

  • Cela augmente le couplage entre les classes, car certaines classes ont besoin d'autres classes, etc. Avoir des beans statiques signifierait que vous les appelez quand vous le souhaitez, sans qu'ils interfèrent réellement dans vos attributs: ce serait comme appeler des méthodes utilitaires, mais elles sont écrites ailleurs.
  • C'est parfois un cauchemar à gérer, surtout lorsque vous avez une configuration orientée xml sur un projet hérité que vous devez gérer.
  • Si vous avez besoin de plus de dépendances dans votre classe (j'en ai une mignonne avec quelque chose comme 26 attributs que j'essaie de réduire en morceaux), vous voudriez la réduire en classes plus petites, mais ces classes peuvent avoir besoin de beaucoup de haricots pour fonctionner, donc vous coupez à nouveau. Cela apporte beaucoup de complexité à la scène.

Je travaille sur un projet LOC de 70k-ish Java, et c'est ma toute première expérience dans le domaine. J'essaie d'améliorer la conception de cette application web, et je pense que j'ai raté les points clés de Java beans avec Spring.

La question est donc: est-ce que l'utilisation de classes statiques pour les beans est une mauvaise idée/une mauvaise conception? Qu'est-ce qui serait bon?

Question bonus: des conseils pour décomposer avec élégance (avec élégance?) Une application Spring Bean?

Je vous remercie

PS: J'ai déjà lu cette question connexe qui traite plus des états des classes/beans et comment l'éviter, que de la staticité des beans en tant que mauvaise/bonne conception.

[~ # ~] modifier [~ # ~]

(Désolé pour le retard, impossible de publier le code) Voici un exemple de ce qui peut être trouvé et de ce qui m'a fait réfléchir à cette question:

// Bean managed in a spring-context.xml
public class HugeMapper  {

    @Autowired
    // Used here only
    private MapperBean    mapperBean;

    @Autowired
    // Used here only
    private ServiceBean   serviceBean;

    @Autowired
    // Used in a couple of classes
    private UtilitaryBean utilitaryBean;

    @Autowired
    // Used in a couple of beans
    private UsefulBean    usefulBean;

    @Autowired
    // Used in nearly half the components
    private OverusedBean  overUsedBean;

    // Code treatment ...
}

La question concerne les haricots utilisés dans de nombreux endroits différents. Les rendre statiques supprimerait la dépendance, mais je ne sais pas quelles seraient les conséquences, et si c'est une bonne/mauvaise conception.

javadesignobject-orientedobject-oriented-designspring
5
Yassine Badache

La statique n'est pas une bonne idée, pour plusieurs raisons:

Presque tous les inconvénients ci-dessus peuvent également être utilisés pour expliquer pourquoi les beans Spring statiques sont une mauvaise idée.

Cela augmente le couplage entre les classes, car certaines classes ont besoin d'autres classes, etc. Avoir des beans statiques signifierait que vous les appelez quand vous le souhaitez, sans qu'ils interfèrent réellement dans vos attributs: ce serait comme appeler des méthodes utilitaires, mais elles sont écrites ailleurs.

Si je comprends bien (vous ne montrez pas de code), vous cachez ainsi la vraie complexité de vos classes. Cela me rappelle le modèle Service Locator (un anti-modèle comme Singleton, enfreint la loi de Demeter et aussi hide les dépendances). C'est une bonne chose d'exposer les dépendances de vos classes, car cela expose mieux quand quelque chose de vraiment mauvais se produit sur les dépendances de classe et il est plus facile de les tester unitairement.

C'est parfois un cauchemar à gérer, surtout lorsque vous avez une configuration orientée XML sur un projet hérité que vous devez gérer.

C'est la raison d'avoir des annotations de nos jours :)

Si vous avez besoin de plus de dépendances dans votre classe (j'en ai une mignonne avec quelque chose comme 26 attributs que j'essaie de réduire en morceaux), vous voudriez la réduire en classes plus petites, mais ces classes peuvent avoir besoin de beaucoup de haricots pour fonctionner, donc vous coupez à nouveau. Cela apporte beaucoup de complexité à la scène.

Je ne pense pas que casser un code gros et complexe en petits morceaux ajoute de la complexité. Si cela ajoute de la complexité à votre cas, vous vous trompez :). Je recommande de lire SRP

Question bonus: tout conseil sur la façon de décomposer avec élégance (avec élégance?) Une application Spring Bean?

Une bonne approche pour l'utilisation de Spring Beans est décrite ici . En général, la meilleure approche consiste à utiliser le constructeur Spring Bean pour injecter les dépendances.

¹. Pas vraiment un problème avec les beans Spring, car ils sont Singleton par défaut.

8
Dherik