En esta entrada voy a dar una "vista de pájaro" sobre qué son los patrones de diseño de software y qué papel tienen en el desarrollo de proyectos software.

Intentaré responder a las preguntas siguientes ¿de verdad es tan importante tener una disciplina a nivel de codificación? Con lo "pocos divertidos" que son ese tipo de libros, ¿tengo que leerme uno que hable de este tema?

Un patrón de software es una técnica de diseño de software que soluciona una clase de problemas concretos.

Muchas veces nos encontramos frente al mismo problema una y otra vez, y optamos por soluciones distintas, perdiendo tiempo de desarrollo en encontrar una solución. Además, como no la hemos “guardado”, puede que olvidemos esa solución y que la siguiente vez que nos encontremos ese problema, tengamos que volver a realizar todo el proceso de nuevas.

Por ejemplo, permiten tener una solución a la falta de herencia de implementación múltiple en lenguajes que no la soportan (Composite), modificar funcionalidad a código que no deseamos tocar (Decorator) o que objetos establezcan comunicación unidireccional con otros sin conocer de su existencia (Observer).

En primer lugar, hay que conocerlos, el famoso libro de "The Gang of Four" (Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides) Patrones de Diseño ofrece una panorámica de los patrones de diseño más comunes, con ejemplos y bien explicados. Hay otros libros y recursos en internet para aprender estas técnicas, y debido a su gran número no listaré todos aquí. Si cabe tener una mención especial por el libro Head First on Design Patterns, que siguiendo con la técnica metodológica de esta serie de libros es mucho más ameno que el anteriormente comentado.

Una vez que se hayan estudiado, debemos buscar ejemplos de proyectos anteriores en los que inadvertidamente hayamos hecho uso de ellos. Así podremos entenderlos mejor. Por último, queda ante un nuevo proyecto, diseñar una buena arquitectura software identificando cada uno de los problemas y posibles patrones para solucionarlos (si los hay, que no es siempre el caso). Hasta que no los hayamos usado al menos una vez, no los conoceremos a fondo.

En primer lugar, tal y como hemos dicho antes, ahorran tiempo. Evitan tener que volver a "reinventar la rueda" ante un problema que ya ha sido resuelto por otros ingenieros. Puede que tengamos que pensar aspectos de implementación, pero la estructura del software es la misma siempre.

En segundo lugar, desde el punto de vista de la ingeniería, no podemos olvidar que toda herramienta de ayuda es poca, y si además, obliga a todos los desarrolladores a seguir una misma metodología mejor todavía. Es decir, logramos uniformidad en el equipo de trabajo, obteniendo un método de trabajo más similar entre los miembros de éste y un vocabulario común que hace más fáciles los desarrollos conjuntos.

En mi caso, yo comencé a trabajar como desarrollador antes de aprender los patrones (en mi universidad no se explicaban), y al estudiarlos pude ver cómo varias de las soluciones que yo había encontrado obedecían a patrones de software, y cómo me hubiera ayudado bastante en otros proyectos, reduciendo el tiempo de desarrollo y haciendo que el código fuese más mantenible.

Como ingenieros hemos de estar constantemente actualizándonos tanto en tecnologías como en técnicas de desarrollo, de manera que si desarrollamos código para un proyecto, éste sea lo más estándar y correcto posible, tanto a nivel de funcionalidad como a nivel de estructura. No olvidemos que un ingeniero ha de poder realizar todas las etapas del desarrollo de un proyecto, incluyendo la fase de codificación.

Diego J. Romero