Polymorphic Rants

In a certain way this article is enlightnening some of my rants about why I have clashes with colleagues in the IT industry.

…but does this mean that agile is not a good way of managing enterprise projects ?? (and saying enterprise I’m thinking at projects with big heavy infrastrucuture – EJB and friends -).

..or probably is just a matter of attitude, no matter the technology and how much burden we’re adding to the architecture ??

I know that is not really professional to change the blog theme every three months or so, but who cares ? Yesterday I found freshy and has been love at the first sight! Still have to tweak a bit the side menu but this theme is sooo sexy !!!

public class Entity implements Serializable {
/** Name of the entity. */
private String name;
Can a name attribute in an Entity class represent something different than the name of the entity ??

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.

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.

At the end of June the University of Insubria (Varese, Italy) will held the second edition of the ESSAP, a full week on agile programming.
It’s a great opportunity to study for a full week what agile really is, talking about agile principles and studying which practices are more suitalbe for agile development.

See you there !!!