Renan Huanca

Nota preliminar
El presente articulo es resultado de la lectura del libro First Head Design Patterns. Después de haber leído un poco el libro y haber aplicado algunos conceptos, veo que es importante compartir estos principios para lograr que el trabajo que realizamos los desarrolladores sea mas fácil y mas efectivo.

Introducción

A lo largo del desarrollo de una aplicación el 99.99% de las veces nos vemos obligados a modificar lo que ya habíamos definido.

El la vida real, las razones son muchísimas, pero acá listo algunas genéricas:

• Nuestro cliente nos pide una modificación por que alguna circunstancia cambio.
• Nos damos cuenta que lo que definimos no estaba bien.
• Encontramos un punto de mejora.

Entonces podemos concluir que solo hay una constante en el transcurso de la fase de desarrollo:

Encapsulación

Para afrontar este reto solo tenemos la opción de en lo posible discernir que partes de nuestra aplicación cambien mas y cuales no.

Osea, si vemos que hay aspectos de una aplicación que cambiaran muy frecuentemente, por decirlo así por cada con cada requerimiento del cliente entonces tenemos que separar ese aspecto de los demás y encapsularlo para que después podamos modificarlo sin afectar al resto de la aplicación.

Es ahí donde nacen los Patrones de diseño, y si me permiten decirlo fue uno de los grandes aportes de la Programación Orientada a Objectos y Java.

Un ejemplo

Uno de los ejemplos mas claros que encontré fue el patrón Modelo Vista Controlador.

El patrón MVC (en su abreviación en ingles), nos permite separar la lógica de control de los datos y de la vista.

Revisemos paso a paso que es cada elemento:

Vista, es el elemento que se encarga de desplegar datos. generalmente en el mundo java son jsps.
Controlador, es el elemento encargado de recibir los pedidos hechos por la vista y ejecutar o llamar a algun metodo para procesar la información enviada.
Modelo, es el encargado de manejar la información al nivel de la base de datos.

Este problema fue resuelto muchísimas veces. la mas básica siempre fue con servlets. Denle un vistazo a este ejemplo de MVC usando servlets.

Extraje una porción del código para poder ser explicado.

(fuente: Arquitectura MVC : El Controlador)

private void 	procesarPeticion(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
	String url = request.getRequestURI();
	String accion = null;
	// no siempre voy a recibir una accion por lo que hay que prevenir errores
	if(url.contains(".accion")){
		accion = url.substring(url.lastIndexOf("/") + 1 , url.indexOf(".accion"));
	}else{
		accion = "inicio";
	}
	if("Estadistica".equals(accion)){
		// Si quiero mostrar las estadisticas:
		Estadistica es = new Estadistica();
		es.mostrarEstadisticas(request, response);
 
	}else if("Guardar".equals(accion)){
		// Si quiero guardar una opinion
		EncuestaAccion ea = new EncuestaAccion();
		ea.recogeDatos(request, response);
	}else{
		// Si no, dirijo al índice
		Inicio i = new Inicio();
		i.muestraIndex(request, response);
	}
}

Como notaran en el código, se tiene un método llamado procesarPeticion. En el cual hay una secuencia de sentencias if para definir que porción de código ejecutar.

Que es lo que cambia? Lo que cambia son las porciones de codigo dentro de las sentencias if.

Que es lo que no cambia? Lo que no cambia son las sentencias if, claro cambiara un poco el string que que compara, pero por lo general esta estructura se mantienen siempre en cualquier servlet que este implementando MVC.

Que es lo que se separa con la encapsulacion? Lo que se separa sera sencilla y simplemente las sentencias if.

Para que separamos lo que no cambia? Separamos para que el resto del código se pueda modificar sin afectar el resto. Es decir queremos la habilidad de solamente escribir código que realizar las operaciones necesarias sin afectar el código que esta alrededor o aumentar ilegibilidad.

Como se aplica la Encapsulación?

Es acá donde se aplica este principio de identificar los aspectos que cambian y separarlos de los que no.

Y en esta tarea uno de los primeros frameworks que tuvo éxito fue Struts.

Struts Abstrajo el aspecto que siempre se repite, que es el de ejecutar una porción de código basado en un parámetro, lo encapsulo y nos dejo a los desarrolladores la parte que cambia.

Lamentablemente no pude encontrar un ejemplo de struts en español, pero encontré un en ingles que habla del DistpatchAction.

Acá un ejemplo de código de como seria la anterior sevlet usando el DistpatchAction de struts.

 
public class EncuestaAction extends DispatchAction
{
 
	public ActionForward estadistica(
	ActionMapping mapping,
	ActionForm form,
	HttpServletRequest request,
	HttpServletResponse response) throws Exception{
		System.out.println("You are in add function.");
		// Si quiero mostrar las estadisticas:
		Estadistica es = new Estadistica();
		es.mostrarEstadisticas(request, response);
	}
 
	public ActionForward Guardar(
	ActionMapping mapping,
	ActionForm form,
	HttpServletRequest request,
	HttpServletResponse response) throws Exception
	{
		// Si quiero guardar una opinion
		EncuestaAccion ea = new EncuestaAccion();
		ea.recogeDatos(request, response);
	}
}

Esto es lo que se gana con la encapsulacion:

• Código mas legible
• Se definen metodos para las operaciones que se necesitan.
• Ya no nos preocupamos de mantener instrucciones if y mantener casos especiales

De esta forma, Struts a encapsulado lo que cambia en favor de permitirnos modificar y adicionar métodos solo para lo que necesitamos. Si usáramos la servlet cualquier modificación afectaría a lo que esta alrededor de esta. Imagínate manejar excepciones. Seria un caos. tendría que decidir si colocar un try catch dentro de cada porción de código que necesita o talvez uno global y luego manejar casos especiales.

Si tienen comentarios o creen que falta mejorar los ejemplo por favor conocer.

Acá les dejo unos links para consulta adicional:

• Arquitectura MVC : El Controlador
• Struts Dispatch Action Example
• MVC en Spring (Blog de Alex Fuentes)
• Como usar el MultiActionController de Spring 2.5

Renan Huanca Principios de Programacion