Are Spring beans declared as static a poor design choice?

Question

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

(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 between 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 advice 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.

Answer 1

Static is not a good idea, for many reasons:

• They are harder to mock in unit tests
• Permanent memory consumption¹
• Is procedural
• And some other disadvantages

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

It increases the coupling between 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 advises 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.}

Answer 2

I work in a project that did this, because the senior refused to track all those objects some of his non-component entities needed. It has been a 7 year fight to unpick this mistake since the senior left. It is throwing random Runtime errors when unittesting, and hiding several high complexity objects in the system resulting in systematic underestimation of effort. Here is where we're going instead:

Any use of static access to spring beans is being evaluated, and either adding the bean as a constructor method, if there is a reasonable means to do so, or being converted into a static utility method for now, because some of the things we gear up an entire bean for are also not right. I know static utility objects aren't the best and part of how we got in this mess, but it's become problematic enough that we need to break this pattern as soon as possible.