icono_twiter icono LinkedIn icono Facebook Icono Xing
Roberto Canales Mora

Creador y propietario de AdictosAlTrabajo.com, Director General de Autentia S.L., Ingeniero Técnico de Telecomunicaciones y Executive MBA por el Instituto de Empresa 2007.
Twitter:

Autor de los Libros: Planifica tu éxito: de aprendiz a empresario y Informática profesional, las reglas no escritas para triunfar en la empresa

Puedes consultar mi CV y alguna de mis primeras aplicaciones (de los 90) aquí

Ver todos los tutoriales del autor

Fecha de publicación del tutorial: 2004-05-17

Tutorial visitado 58.518 veces Descargar en PDF
Aplicación de Técnicas Avanzadas de Diseño

Aplicación de Técnicas Avanzadas de Diseño

La evolución tan rápida de las nuevas tecnologías Java o .Net propicia un problema muy curioso:

Invertimos más tiempo aprendiendo técnicas relacionadas con el modo de hacer las mismas cosas (comunicaciones, acceso a datos, formateo, etc.) que en refinar nuestras técnicas de estimación, dirección de proyectos, análisis, diseño...

Es un poco triste ver en el día a día del trabajo que la gente empieza a utilizar técnicas de Java 1.5 (porque está ahora de moda) y no saben apenas que es el polimorfismo, tienen conocimiento teóricos mínimos de UML (de lo que recuerdan en la universidad en el mejor de los casos) y un desconocimiento total (o casi) de las técnicas avanzadas de diseño (como patrones de diseño).

Esto provoca que nos lancemos a escribir código demasiado deprisa y que tengamos que parchearlo constantemente quedando al final una chapuza inmantenible que nos llena de insatisfacción.... (supongo que os suena).

Hasta que todo el mundo no sea consciente que construir un programa es como construir una casa y que hay que invertir un gran esfuerzo en diseñar antes de empezar a escribir..... el problema será siempre el mismo....

Hoy vamos a plantear de como diseñar una solución con técnicas avanzadas de diseño para abriros un poco la inquietud por estas técnicas. Veréis de modo inmediato que sin conocimientos de UML.... no podemos discutir entre arquitectos.

Patrones aplicados a Java

Supongamos que tenemos que hacer una aplicación para mostrar los movimientos bancarios de un cliente.

Podríamos crear una clase que tenga el método que nos permitirá recuperar los datos de nuestro cliente.

Si posteriormente tenemos que cambiar procedimiento de acceso, podemos retocar nuestro código pero ¿cómo podemos volver atrás fácilmente? ¿cómo podemos tener disponible los dos códigos al mismo tiempo?

Podríamos crear una clase abstracta que defina el comportamiento base y una clase derivada con la implementación particular que necesitamos (esto es polimorfismo puro).

Es más, podemos inicialmente crear una clase derivada que nos proporcione datos de prueba para que el resto del equipo pueda continuar trabajando sin que el acceso real este construido.

Como en todo sistema, los datos de nuestros clientes estarán distribuidos entre el sistema OnLine y el sistema Batch. Podemos crear una tercera clase que sea la encargada de devolver los datos históricos.

Deberemos, en la medida de lo posible, utilizar interfaces en lugar de clases (que nos ayudan a heredar comportamientos dejándonos la libertad futura de poder heredar código )

La clase que obtenga y muestre los datos, realmente tendrá que usar uno o más de uno de estos objetos para recuperar los datos.

Los datos que retornemos los agruparemos en objetos simples (Value Objects). Los Value Objects implementarán un interfaz marcador VO para identificarlos fácilmente. Para que se puedan manipular indistintamente de la estructura que defina internamente cada clase (principios de encapsulación y abstracción) los métodos retornarán un Iterator.

Supongamos que la clase cliente tiene que usar estas clases para recuperar los listados...... podemos crear una factoría (clase especializada en crear los objetos adecuados) para que sea una clase externa la que tenga la lógica particular de la aplicación.

 

Esta estructura está bien pero debemos seguir los principios básicos de asignación de responsabilidad (ver patrones de GRASP). La clase gestora, la factoría y el acceso a datos están altamente acoplados. Si quisiéramos reutilizar el modelo en otra aplicación deberíamos cambiar la factoría (podríamos volver a utilizar polimorfismo).


Hay otra técnica que es más adecuada, lo que se denomina inversión del control. Podemos hacer que la clase GestorListadoMovimientos tenga un método que permita establecer los objetos de AccesoDatosCliente adecuados. De este modo, rompemos la relación permanente entre la factoría y el gestor. Además, con este modelo, la extracción de las variables particulares del interfaz Web (request y response) nunca deberían pasar del configurador, lo que garantiza una buena portabilidad de la aplicación.

Fijaos que estamos diseñando el sistema y todavía no hemos hablado ni donde están los datos ni el tipo de aplicación que estamos construyendo (aquí esta un poco la gracia del modelado de negocio).

Si fuera una aplicación Web, posiblemente tuviéramos un servlet que recibiría la petición y delegará sobre un JSP para pintar los los datos (obtenidos a través del Gestor proporcioando por el configurador, relación que no hemos representado en el siguiente modelo por ser obvia ).

Este servlets utilizaría el configurador para obtener un GestosListadoMovimientos con sus objetos AccesoDatosCliente ya asignados.

Seguro que nuestro JSP recibirá una lista de VODatosCliente que tendrá que pintar (y lo podría hacer utilizando el patrón "helper", es decir, ayudandose de una etiqueta personalizada).

 

Evaluando el modelo

Debemos hacernos unas pequeñas preguntas para ver que tal llevamos el modelo.

  • ¿Que debería cambiar si añadimos más campos?

    Solamente VOCliente, las clases que los generan (Acceso a datos específicos) y el Tag (de presentación) particular.

     

  • ¿Si fuera una aplicación no Web?

    Valdría todo excepto lo particular de la presentación.

     

  • ¿Si los datos estuvieran más dispersos?

    Crearíamos solamente más clases derivadas de AccesoDatosCliente y cambiaríamos el configurador.

     

  • ¿Donde conectamos a la base de datos? ¿en el servlet?

    No hemos dicho todavía si hay base de datos. Serán las clases de acceso las que deberían abrir las comunicaciones y cerrarlas (esto cambiaría si tuviéramos necesidad de gestionar transacciones).... pero no el servlet (esto a más de uno le va a dar que pensar)

 

Conclusiones

Todo el esfuerzo que se invierta en la fase de análisis y diseño será dinero y tiempo ahorrado en construcción y despliegue. Lanzarse a codificar desde el primer día solo provocará acumulación de problemas.

Aprender UML y técnicas de diseño es vital. También hay una cosa a tener en cuenta.... el exceso de diseño es tan malo como el defecto y hay algo que aun es peor: aprender una técnica y tratar de aplicarla en todos los casos. HACE FALTA ENTRENAMIENTO PARA OBTENER CRITERIO.

El modelo que habéis visto aquí valdría para cualquier tipo de aplicación ..... aunque es un poco incompleto (ya os iremos contando más sobre estas técnicas). Para aplicaciones empresariales, revisad otro de nuestros tutoriales que hacen referencia a los patrones de diseño J2EE.

Bueno, si estáis en Madrid, siempre me podéis contratar para ayudaros en vuestros proyectos y/o daros algún curso o charla sobre el tema  ...

A continuación puedes evaluarlo:

Regístrate para evaluarlo

Por favor, vota +1 o compártelo si te pareció interesante

Share |
Anímate y coméntanos lo que pienses sobre este TUTORIAL:

Fecha publicación: 2009-12-14-13:44:19

Autor: jcarmonaloeches

Bien bien, esto pica y obliga a crecer...

Bien, gracias!

Fecha publicación: 2009-04-23-07:33:35

Autor:

[JuserNt] Gracias x los consejos

Fecha publicación: 2007-06-08-04:32:07

Autor:

[julian b] este tutorial en realidad dice tanto que no dice nada. Muy malo.

Fecha publicación: 2006-10-31-11:27:09

Autor:

[CARINA] BIEN

Fecha publicación: 2006-04-28-03:17:05

Autor:

[luis abarca] Muy buen tutorial muchas gracias me ayudo mucho