Return to Answer

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 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.}

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.}

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 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.

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 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.}

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 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.

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 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.