« Atrás

Introducción a los Patrones de Diseño : ¡no reinventes la rueda!

Diseñar Software es una tarea compleja. Cuando trabajamos con el paradigma Orientado a Objetos hay que decidir cuantos objetos va a tener el sistema, de qué tipo serán, cómo interactuarán entre ellos, qué relaciones de herencia, dependencia y composición existirán, etc. Para resolver una misma problemática (un mismo requisito funcional) podemos trabajar con cientos de diseños distintos.

Lo primero que quiero dejar claro es que el diseño es una tarea que hay que ejecutar en todos los proyectos de Desarrollo de Software, al menos, aquellos que estén enfocados al desarrollo de aplicaciones empresariales. Dejar a nuestros programadores escribir código sin ninguna dirección podría tener consecuencias desastrosas (muy alta probabilidad) y además impide realizar con garantías las tareas de gestión sobre el proyecto. Cuando hablamos de diseñar en Orientación a Objetos hablamos de tomar decisiones sobre qué clases, qué interfaces, qué relaciones (herencia, dependencias, agregaciones, composiciones) vamos a construir. La forma normalizada de representar estos diseños es a través de diagramas UML (Lenguaje Unificado de Modelado), por ejemplo, a través de diagramas de clases y de secuencia. En el mercado podemos encontrar soluciones enfocadas a la generación de dichos diagramas y a su documentación, son las llamadas herramientas CASE (ejemplos de ellas son Poseidon UML, UML Umbrello o la archiconocida Enterprise Architect) y también podemos realizar las mismas labores con los entornos de desarrollo integrados (IDEs) más populares como Eclipse o Netbeans.

La primera pregunta que cabe plantearse es ¿importa el diseño a la hora de hacer Software?. Mi respuesta es rotunda: el diseño es muy importante y al igual que las decisiones de arquitectura marcarán el devenir del proyecto. Por ejemplo, un buen diseño (con suficiente grado de generalización y las dependencias controladas) hará que los costes de mantenimiento de un proyecto sean asumibles y estén controlados, mientras que un mal diseño terminará por hacer que el proyecto se convierta en inmantenible.

Cuando diseñamos buscamos diseños específicos para el problema que estamos manejando, pero lo suficientemente generales para adecuarse a futuros requisitos y problemas. Queremos encontrar los objetos necesarios, factorizarlos en clases con la granuralidad adecuada y definir interfaces de clases que perduren en el tiempo.
¿Cómo podemos hacer diseños para nuestro software de manera que este sea de calidad (reutilizable, mantenible, extensible, ...)?
 

Documentar las buenas experiencias : Patrones de Diseño
 

El Diseño Orientado a Objetos es una tarea en la que llevamos años trabajando. En la década de los 90 varios autores (Erich Gamma, Richard Helm, Ralph Johnson, John M. Vlissides) identificaron problemas recurrentes que aparecían en las fases de diseño de muchos proyectos de software.

Por ejemplo, “crear un objeto complejo desde un cliente de una manera simplificada y sin conocer los detalles del objeto que se está creando” o “impedir que se creen más de un objeto de un determinado tipo” ilustran este concepto de “problema de diseño recurrente”.

Pues bien, identificados estos problemas, las soluciones a los mismos fueron llamadas “patrones”. Es decir, un patrón de diseño no es más que una guía para solucionar un problema recurrente de diseño. Pero ¡cuidado! ... no cualquier solución vale. Tienen que ser soluciones probadas y de calidad, que nazcan de la experiencia y el consenso de un amplio grupo de profesionales.

En el año 1995 los cuatro autores previamente mencionados (que informalmente se conocen como el “Grupo de los Cuatro” o por sus siglas en inglés GOF) publicaron el primer libro en el que formalmente se estudiaban los patrones de diseño: Design Patterns: Elements of Reusable Object-Oriented Software.

Gang of Four (El grupo de los cuatro, los pioneros en patrones de diseño Software)

Como ya hemos dicho, un patrón de diseño no es más que una receta de éxito, muy valiosa porque nos está transmitiendo de una manera sencilla la experiencia acumulada durante muchos años de personas que han estado peleándose con el mismo problema que tenemos delante. No obstante, aquí os dejo algunas definiciones más formales sobre los patrones de diseño:


“un patrón de diseño es una descripción de clases y objetos comunicándose entre sí adaptada para resolver un problema de diseño general en un contexto particular.” (Gamma)

“un patrón describe un problema que ocurre una y otra vez en nuestro entorno, así como la solución a ese problema, de tal modo que se puede aplicar esta solución un millón de veces, sin hacer lo mismo dos veces.” (Christopher Alexander)

“El patrón de diseño es una solución a un problema de diseño no trivial que es efectiva y reusable.”

Algunas preguntas frecuentes sobre Patrones de Diseño

¿Los patrones de diseño reducen el número de líneas de código que tenemos que programar?

¡NO! ¡El número de líneas de código puede verse fuertemente incrementado! Sobre todo a corto plazo. El objetivo de los patrones es dar diseños de calidad. Para conseguir esto es habitual tener que programar clases, interfaces y otros artefactos que no estaban inicialmente previstos pero que aportarán calidad a nuestro software (lo harán más flexible o más mantenible, por ejemplo). Ejemplos de estos artefactos son por ejemplo una clase "factoría" especializada en crear objetos o una interfaz "adaptador". Además, el "número de líneas de código (LOC)" es una métrica de la fase de implementación y la fase de implementación es posterior a la de diseño. Los patrones de diseño, como su nombre indica, resuelven ¡problemas de diseño! y no están enfocados a que nuestra algorítmica sea más escueta.

¿El código de los patrones de diseño se reutiliza?

¡NO! ¡Creo que estás pensando en Copy&Paste! ¡ Los patrones ayudan a reutilizar las estructuras de diseño que aplicamos! Si quieres, puedes verlo como que se reutiliza la "filosofía de resolución de un problema de diseño". El código fuente que implementa las clases e interfaces propuestas por un patrón de diseño en distintos proyectos será completamente diferente. Las implementaciones de los patrones difieren en un sistema y otro, ¡lo que reutilizamos son las soluciones de diseño y no el código!

 

Continuará... Estoy escribiendo varios post que profundizan e ilustran este tema de manera más práctica. No olvides seguirnos en twitter para estar al día ;-)

Comentarios
URL de Trackback:

comments powered by Disqus