Polymorphic Rants

Spring is a good framework: it’s pretty powerful but still quite lean, the border of each functionality is quite well defined.

But it’s still a nonsense to use Spring for everything: there are scenarios where using the framework means just increase the complexity.

Let’s take a real world example (and with real world I mean I’m actually working on a scenario like this ):
a specific component in our architecture should be a Singleton (let’s forget for the time being the “singleton is evil” topic).

A pretty standard implementation is:
public MyObject {
public static synchronized getInstance() {
//create the instance -if necessary- and return it
}
//the other behaviours
}
What are we achieving through this implementation ?
We are clearly explaining our design. Every engineer that will look at this class will know that this is a Singleton and will argue that this is a strategic decision in the design of the application.But (sadly) sounds like that enforcing the Singleton pattern through Spring is more hype
So we end up with something like:
public MyObject {
//behaviours...
}
and in a separate xml the Spring configuration:

[...]

bean id=”TheSingleton” class=”Myobject” scope=”singleton”

[...]

This is bad!

Why ?? Because we’re adding the complexity of an additional xml file for free, without having any useful help from the framework.

With the latter solution you don’t understand that MyObject is a singleton just looking at the code, but you have to check also the Spring configuration file !! In this way, Spring instead of acting in a transaparent way (i.e. just do the dirty work and take away from me the boilerplate code) is becoming a part of the design, we understand one of the patterns used in the application reading a configuration file.

In a word: The complexity is growing and the clarity of the design is going down: is this not enough to say that this is bad decision?

I think so.