Patrones de diseño de software.

He hablado mucho sobre el tema, en los últimos post, incluso los he ejemplificado, y al igual que con otros temas dentro de este Blog, cometí el error de creer que todo el mundo debe haber escuchado de ellos, o al menos saber lo que son y lo que no son.

Así que ahora voy a tratar de exponer lo que para mí son los patrones de diseño de software.

Según la historia (y solo esto diré al respecto) los patrones se remontan hasta 1970, cuando un tal Alexander expuso una definición en la que los presentaba.

 

Pero de donde se originan?

Se originan de la experiencia y el conocimiento de programadores a través de muchos años de uso. Mismos que fueron recopilados y catalogados por un grupo conocido como Gang of Four.

 

Para que sirven?

Para definir soluciones comunes a problemas complejos. Creando un estándar de conocimiento, y comunicación entre los miembros de un equipo de desarrollo. Donde, basados en el conocimiento compartido de dichos patrones, no es necesario entrar en detalles de la implementación de una solución, solo se requiere saber que patrón aplicar.

 

Para quien son?

Si tu eres un programador con varios años de experiencia en lenguajes orientados a objetos, si hasta trabajado con clases en .NET, es muy probable que hayas empleado alguno de estos patrones, sin que tengas conciencia de ello; pudo haber sido por un ejemplo obtenido en internet, por un ejemplo de algún libro o simplemente la experiencia te ayudo a llegar a la misma conclusión que aquellos quienes los clasificaron hace tanto tiempo. Los patrones son para ti.

 

OK, entonces que son y que no son?

Son una forma de reutilizar una solución. Suena algo ambicioso, ya que quienes trabajamos en esto tenemos la idea, que cada proyecto presenta retos diferentes, que deben atenderse con soluciones ad hoc; sin embargo, en la medida que logramos identificar las partes individuales y encontramos las similitudes, entonces podremos valorar la forma de aplicar una solución que ha sido empleada muchas veces a lo largo del tiempo. Se traduce en menos tiempo y menos errores.

No son la solución a todos nuestros problemas. Debemos estar claros que a pesar de tratar de encontrar las similitudes de las que hemos hablado en el párrafo anterior, no siempre se puede. Tratar de aplicar un patrón a algo simple podría resultar en un código mucho más complejo de lo necesario. Para poder identificarlo se requiere experiencia.

 

Un consejo final.

Si a la primera llegas a la solución y resulta ser un código, simple (no simplista*) y es fácil de mantener y el código es de calidad, no es necesario devanarte el cerebro tratando de usar un patrón.

Aclaración:

Quiero hacer la aclaración de que este post es desde mi experiencia personal, y con esto quiero evitar las polémicas que podría generar un tema tan controversial entre mis conocidos. También quiero que quede claro que he tenido la oportunidad de usarlos en proyectos reales en los últimos meses y que los he aprendido sobre la marcha, hay muchos lugares donde pueden encontrar explicaciones muy técnicas con los lineamientos y definiciones oficiales; no es mi intención hacer algo así. Solo quiero exponerlo con mis palabras.

*Simplista Significa: Que está basado en ideas demasiado elementales.