Method Refactoring

[info]bpfurtado has raised an important question concerning some odd practices in software programming. People who code applying the same paradigm to all computer languages, thinking the only difference between programming languages are all about their syntax and grammar. These kind of code generate a lot of bad consequences, like the one I will focus at this post.

Sometimes I see people writing methods like “doX&Y&Z”, reflecting more than one responsability inside a method. Clearly this kind of design isn’t focused on reuse and maintenance, because people who code this way don’t even know such practices, characterized in OO programming. Methods must be cohesive, that is, “a cohesive method is responsible for one and only one well-defined logical task”.

Such a method could be factored into three little private methods, named “doX”, “doY” and “doZ”. To one public method is given the responsability to coordinate the tasks between the three methods. Talking about the former approach, how can you reuse one of the computation inside the “big” method? It’s impossible. So, reuse and maintenability is better achieved in the latter approach.

It occurs that people start programming in a language without knowing the paradigm it applies. So, people need to change their mind to produce better code, otherwise real big projects will continue to suffer the same problems we are tired of hearing nowadays.

Integrating Struts and Spring

My coworker Max has argued with me there is no relationship between Java web based frameworks, specially Struts and Spring. Well, I completelly disagreed with him when he raised this question and here I will post one of the possibilities of their integration. This alternative let you configure Spring to manage your Actions as beans, using the ContextLoaderPlugin, and set their dependencies in a Spring context file. Here are the steps to apply this configuration:

Add the following XML snippet to the plug-ins section near the bottom of your struts-config.xml file:

<plug-in className=”org.springframework.web.struts.ContextLoaderPlugIn”/>

Now you can configure your actions to be injected by Spring. One way you can do this is use the DelegatingActionProxy class in the type attribute of your <action-mapping>.

This way of configuration allow you to manage your Actions and their dependencies in the action-context.xml file. The relationship between the Action in struts-config.xml and action-servlet.xml is established by the action-mapping’s
“path” and the bean’s “name”. If you have the following in your struts-config.xml file:

<action path=”/employees” …/>

You must define that Action’s bean with the “/users” name in action-servlet.xml:

<bean name=”/employees” …/>

Defining your Action in a context file let you to use Spring’s IoC features, as well as instantiate new Actions for each request created. To do this, add singleton=”false” to your action’s bean definition.

<bean name=”/employees” singleton=”false” autowire=”byName” class=”org.myapplication.web.EmployeeSearchAction”>

To be more concrete, here is a complete example of an Action described in struts-config.xml:

<action input=”/index.jsp” name=”mainForm” path=”/login” scope=”request” type=”org.springframework.web.struts.DelegatingActionProxy”> <forward name=”main_page” path=”/main_page.jsp”/> </action>

And here is its version in action-servlet.xml:

<bean id=”action.loginAction” singleton=”false” autowire=”byName” name=”/login” class=””/>

There are more alternatives to inject your actions in Spring. If you want to know the other ones, please check out the Spring reference manual.