Patrones de diseño: usar con moderación

Cómo llegaron a mi vida

La primera vez que escuché hablar sobre patrones de diseño fue en la facultad (de ahora en más los mencionaré como patrones pero sepan que así como hay patrones de diseño también hay de otros tipos, como de arquitectura).  El solo hecho de pensar que ya existían un montón de diseños para ayudar a resolver problemas comunes me voló la cabeza pero a la vez, me generó una presión muy grande que era la de descubrir cómo podía programar la solución al problema que estaba analizando usando un patrón.

En aquel momento, aprendí la teoría y pude poner en práctica alguno de ellos. Sin embargo, aún no tenía experiencia profesional para entender si era realmente una herramienta que usaría a menudo, o simplemente, una de esas teorías que uno aprende y  luego, no utiliza nunca más (#SpoilerAlert: hasta que la muerte nos separe).

Bueno ahora sí, empecemos por el principio. Los patrones de diseño son soluciones documentadas para problemas recurrentes que nos ahorran tiempo y permiten que nuestro código quede flexible y reutilizable. A mí me gusta decir que es una herramienta más con la que contamos quienes programamos. 

Cómo llegaron “al sistema”

En 1979 se empezó a hablar de patrones de diseño, cuando el arquitecto Christopher Alexander aportó al mundo de la arquitectura el libro “The Timeless Way of Building”; en él proponía el aprendizaje y uso de una serie de patrones para la construcción de edificios de una mayor calidad. 

Años después, en 1987, Ward Cunningham y Kent Beck, leyendo a Alexander, se dieron cuenta del paralelo que existía entre la arquitectura propuesta por Alexander y la orientada a objetos.  De este modo,  usaron varias ideas de Alexander para desarrollar cinco patrones de interacción hombre-ordenador (HCI) y publicaron un artículo titulado “Using Pattern Languages for OO Programs”.

Pero no fue sino hasta principios de la década de 1990, cuando los patrones de diseño tuvieron un gran éxito en el mundo de la informática.  A partir de la publicación del libro Design Patterns escrito por el grupo Gang of Four (GoF) compuesto por Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides, en el que se recopilaron 23 patrones de diseño comunes.

Es decir, que estamos hablando de prácticas de diseño que se definieron hace 30 años y siguen vigentes.

Photo by Maximilian Weisbecker

Algunas clasificaciones

Existen diferentes clasificaciones y categorías para los patrones de diseño. A mí me gusta la que simplemente los separa en:

• CREACIONALES Permiten abstraer y encapsular la creación de instancias.
• ESTRUCTURALES Habilitan la solución de problemas de composición (agregación) de clases y objetos, generando estructuras más flexibles.
• DE COMPORTAMIENTO Ofrecen soluciones respecto a la interacción y responsabilidades entre clases y objetos, así como los algoritmos que encapsulan

Seguramente alguna vez aplicaste alguno de estos patrones, ya sea desarrollando alguna solución propia a algún problema o usando algún framework. ¡Sí! Muchos frameworks se basan en patrones de diseño, así que es probable que los estés utilizando sin saberlo.

Patrones y frameworks

Me voy a focalizar en Java porque es el lenguaje en el que tengo mayor experiencia pero se puede aplicar a cualquier lenguaje de programación.

Si trabajás con Java es probable que uses o hayas usado alguna vez Spring, este se basa en el patrón de diseño conocido como Inyección de dependencia (o Inversión de control “IOC”). Donde los objetos no son responsables de inicializar sus dependencias, sino que estas son provistas a través de otro objeto. 

Pero ese es sólo uno de los muchos patrones que utiliza Spring. Algunos de los más conocidos son:

• Singleton (creacional)
• Factory (creacional)
• Proxy (estructural)
• Template (comportamiento)

Por lo cual, si sabés de patrones de diseño, te va a resultar mucho más sencillo aprender frameworks nuevos.

Usar con moderación

Ahora, después de enumerar todos los beneficios de los patrones, ¿por qué digo que debemos “usarlos con moderación” en el título? Si bien considero que los patrones de diseño son muy útiles y todas/todos y todes deberíamos conocerlos, me he  encontrado con código de colegas que lo usaban en exceso, generando implementaciones difíciles de entender y seguir. Por eso, así como es importante saber de patrones, también tenemos que conocer los anti-patrones, para “no caer en el vicio”.

Algunas cosas con las que me he topado en estos años en la industria: 

Código con muchísimas interfaces y capas que solamente tiene una implementación y que no planea generar nuevas, seguramente nos dé la pauta de un caso de “yet another f**king layer” (YAFL, ¡y otra maldita capa más!). Imaginen que tienen el primer contacto con código en un nuevo proyecto, y tienen que navegar entre todas las capas del mismo, capas que quiźas lo único que hacen es ser “pasamanos” entre distintos servicios, esto genera un código excesiva e innecesariamente complejo (lo que se conoce como “gas factory”, fábrica de combustible).

¡Los famosos managers! Clases superpoderosas que hacen todo. Conocido como “God Object”, cuando tenemos clases con muchos métodos, mucha lógica, que hacen más de una cosa, y rompen con el principio de “Single responsability” (la famosa “S” de S.O.L.I.D una clase debe tener una única responsabilidad). Esto interfiere con las ventajas de la programación orientada a objetos, ya que estas clases tan grandes son muy difíciles de mantener, de reusar y de probar. Y si una clase no es fácilmente testeable, denota una alerta en un mal diseño.

En resumen, contamos con una gran herramienta, que son los patrones de diseño, pero como toda herramienta la debemos usar a conciencia y en su justa medida, porque sino, se puede convertir en nuestro peor enemigo (¡o de la próxima persona que tome nuestro código!).

Virginia Barros, Technical Lead @Neginet