4

The question is pretty straightforward, I'll try to explain why I want some explainations.

(All of this is my 1½-year junior Java developer opinion, which may be more than incomplete. Which is why I am asking the question there).

  • It increases the coupling bewteen classes, as some classes need other classes, and so on. Having static beans would mean you call them whenever you want, without them actually interfering in your attributes: it would be like calling utility methods, but they are written elsewhere.
  • It is sometimes a nightmare to manage, especially when you have an xml-oriented configuration on a legacy project that you need to manage.
  • If you need more dependencies in your class (I have a cute one with something like 26 attributes that I try to cut down to pieces), you would want to cut it down to smaller classes, but those classes may need still a lot of beans to function, so you cut down again. It brings a lot of complexity to the scene.

I am working on a 70k-ish LOC Java project, and it is my very first experience in the field. I am trying to improve the design of this web-application, and I think I missed the key points of Java beans with Spring.

So the question is: is using static classes for beans a bad idea / a poor design ? What would be a good one ?

Bonus question: any advices on how to decompose with elegance (elegantly ?) a Spring bean application ?

Thank you


PS: I already read about this related question which treats more about states of classes/beans and how to avoid it, than staticity of beans as a poor/good design.


EDIT

(Sorry for the delay, couldn't post code) Here is an example of what can be found, and what made me think about this 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 ...
}

The question is about the beans that are used in a lot of different places. Making them static would remove the dependency, but I'm not sure about what would be the consequences, and if it is a good/bad design.

  • Here is some code (former to reading all in your answer) – Yassine Badache Jan 25 '18 at 13:19
  • You use it like HugeMapper.getUsefulBean() in your code? – Dherik Jan 25 '18 at 14:18
  • I'm not that monstruous, but if HugeMapper was static, it would be something like HugeMapper.doSomething() which would call beans after beans to make treatments on data. – Yassine Badache Jan 25 '18 at 16:01
  • The could be called ServiceLocator :) (I said about that in my answer). I was trying to understand if you are trying this approach and I'm glad that you are not. – Dherik Jan 25 '18 at 16:20
8

Static is not a good idea, for many reasons:

Almost every disadvantage above can also be used to explain why static Spring beans is a bad idea.

It increases the coupling bewteen classes, as some classes need other classes, and so on. Having static beans would mean you call them whenever you want, without them actually interfering in your attributes: it would be like calling utility methods, but they are written elsewhere.

If I understand correctly (you not show some code), in this way you are hiding the true complexity of your classes. This reminds me of the Service Locator pattern (an anti-pattern like Singleton, breaks the Law of Demeter and also hide the dependencies). It is a good thing to expose the dependencies of your classes, because this expose better when something really bad is happening on the class dependencies and it is easier to unit test them.

It is sometimes a nightmare to manage, especially when you have an xml-oriented configuration on a legacy project that you need to manage.

This is the reason to have annotations nowadays :)

If you need more dependencies in your class (I have a cute one with something like 26 attributes that I try to cut down to pieces), you would want to cut it down to smaller classes, but those classes may need still a lot of beans to function, so you cut down again. It brings a lot of complexity to the scene.

I don't think that breaks a big and complex code in minor peaces add complexity. If it is adding complexity at your case, you are doing this wrong :). I recommend read about SRP

Bonus question: any advices on how to decompose with elegance (elegantly ?) a Spring bean application ?

A good approach for using Spring Beans is described here. In general, the best approach is use the Spring Bean constructor to inject the dependencies.

¹. Not really a problem with Spring beans, because they are Singleton by default.

  • Thank you for the litterature, it will take me a while to read :) BTW I added a relevant piece of code. – Yassine Badache Jan 24 '18 at 8:22
  • 1
    Having static beans would mean you call them whenever you want, This doesn't remove either coupling nor dependency. It only will obfuscate it and, over time, the coupling and the dependency over these beans will go for worse. When a component is present anywhere in the code, it's a design flaw regarding cohesion. Statics will act like global variables what in general, is a bad thing. Mainly because makes the whole application less predictive. Overall if these beans are stateful – Laiv Jan 24 '18 at 10:10
  • I think one of the main points there (that I missed) would be that states on beans are strictly to banish. – Yassine Badache Jan 25 '18 at 13:18
  • 1
    Though I mostly agree with that, I fail to see the point about memory consumption, since a Spring Beans will generally eager instantiated at startup and will remain in memory as a singleton unless you specify otherwise. – Walfrat Jan 11 at 12:10
  • @Walfrat, I was explaining generally the problem, but you are right, Spring Beans are singleton by default. I added this explanation on my answer, thanks! – Dherik Jan 11 at 14:45

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.