¿Qué son patrones de diseño?

Recuerdo los primeros días en la universidad, cursando Programación I. Ansioso por empezar a codificar, cualquier cosa en realidad, no importaba mientras que fuera crear mis primeras líneas de código. No tenía ni idea de que existían los patrones de diseño.

Que equivocado estaba. El profesor que daba el curso empezó a enseñarnos otros temas menos codificar, nos estaba “preparando”. Pasaron casi 3 meses antes de abrir el IDE y programar mi primer Hola Mundo.

Ustedes dirán, que decepción, yo pensé lo mismo, créanme, 3 meses conteniéndose para una simple línea de código. Les juro que pensé, si esto es programar, ya no quiero hacerlo. Estoy seguro que a much@s de ustedes les paso algo similar, los primeros cursos son….algo amargos.

Pero bueno, el tiempo pasó y fue por allá del cuarto cuatrimestre, en Programación IV, cuando descubrí y entendí que antes de saber programar, hay que saber diseñar. Y no estoy hablando de diagramas de clases o de secuencia, sino algo más profundo, lo que en realidad hace la diferencia entre un buen diseño con buenos diagramas a un diseño por salir del paso.

En ese momento fue cuando descubrí los Patrones de Diseño.

Había pasado un año codificando tareas programadas, proyectos, exámenes, en fin, un sin número de aplicaciones y siempre encontraba los mismos problemas. Una y otra vez me preguntaba, ¿cómo podré hacer para que cuando llame a este objeto, siempre me devuelva la misma instancia? O por ejemplo, necesito compartir la información de este objeto con todo el resto de la aplicación.

Las soluciones que se me ocurrían eran, bueno, no eran buenas, ni óptimas, ni elegantes, pero yo estaba seguro que tenía que existir mejores formas de hacer las cosas.

Y fue en Programación IV cuando encontré respuestas de mano de los Patrones de Diseño. Resulta ser, que estos sujetos, llamados patrones, vienen a solucionar problemas que son frecuentes en la mayoría de aplicaciones. La diferencia es que ya hubo otra persona o personas que hicieron parte del trabajo por nosotros y encontraron soluciones a esos problemas frecuentes.

Entonces, un patrón de diseño, podría definirse como, una serie de principios y prácticas que a la hora de implementarse, solucionan uno o varios problemas en el diseño de nuestras aplicaciones. El objetivo de estos patrones es diseñar la aplicación de tal forma que no solo soluciona el problema que teníamos, sino que, además, brinda flexibilidad al diseño para poder extenderlo y mantenerlo en el futuro.

Según el libro “Head First Design Patterns” (Elisabeth Robson, Kathy Sierra, Eric Freeman y Bert Bates), lo único que tienen en común cualquier aplicación, no importa el nicho de negocio, no importa si es Web o Consola, el lenguaje o el motor de base de datos, es que todas cambian.

Cuantas veces nos ha pasado que estamos list@s con el prototipo de la aplicación, terminamos las pruebas (porque como buen@s programadores, hacemos pruebas del código) y vamos a hacer el “deploy”, nos dice el/la Business Analyst o Project Manager, mirá Carlos, el cliente nos acaba de informar que el requerimiento ABC ahora necesita leer archivos con formato XYZ y no con el que habíamos quedado desde el inicio.

Esa situación pasa a veces hasta a diario. El software y la tecnología en general es como un ser viviente que pasa cambiando, y esos cambios algunas veces no son fáciles de manejar e implementar.

Esa es la importancia de patrones de diseño. Nos permiten diseñar nuestra aplicación de tal forma que por más grande o difícil que sea el cambio o el nuevo requerimiento, se puede implementar de una forma relativamente rápida, sin introducir nuevos problemas o errores en la aplicación.

Los patrones de diseño, en su mayoría nacen a partir de principios de diseño, es decir, varios principios de diseño (que ya son parte de cualquier lenguaje de programación orientado a objectos) se juntan y el resultado es un Patrón de Diseño específico.

Por ejemplo, el Patrón de diseño llamado Estrategia (haré otro post solo de patrones específicos), utiliza principalmente 3 principios:

1. Identifique las partes de su aplicación que cambian constantemente y apártelas de lo que se mantiene igual.
2. Programe en las interfaces, no en las implementaciones.
3. Si debe escoger entre herencia y composición, prefiera composición.

En resumen, el patrón Estrategia busca mover los comportamientos de un objeto fuera de las súper clases (apartar lo que cambia), crear nuevas clases padre para esos comportamientos y sus implementaciones específicas (programe a interfaces o súper clases) y por último utilizar los comportamientos padre como atributos del objeto original (prefiera composición sobre herencia).

La Programación Orientada a Objectos cuenta con muchos principios, que, podríamos decir, son reglas que se deben de contemplar antes de empezar a codificar nuestra aplicación.

En futuros posts vamos a ir analizando y describiendo los principales patrones de diseño. Para cada patrón vamos a realizar un diagrama UML sencillo y el código para implementarlo además de ejemplos y prácticas para que lo pongan a trabajar.

Recordá suscribirte aquí para recibir las últimas actualizaciones todas las semanas.

Referencias:
Libro Head First Design Patterns. Versión digital.