Los patrones de diseño son soluciones estándar en diseño de software a problemas habituales. Cada patrón es un heurístico o regla para resolver un problema.

Esta estandarización de soluciones han sido muy útiles por varios motivos.

Los patrones de diseño son un juego de herramientas de soluciones comprobadas a problemas habituales en el diseño de software. Sirven como un catálogo de soluciones que puedes incluir a tu caja de herramientas.

Establece un lenguaje común entre los desarrolladores de software. De esta forma facilita la comunicación en el momento de analizar soluciones a determinados problemas, por ejemplo durante pair programming o revisiones de código.

Con el paso del tiempo algunos de estos patrones han ido evolucionando por la comunidad a considerarse como anti patrones, creando gran confusión entre los desarrolladores de software.

¿Dónde está el problema?

El problema, desde mi punto de vista para popularizar un patrón de diseño como un anti patrón, es la falta de información.

Los patrones de diseño fueron creados para resolver limitaciones de lenguajes y eran útiles para resolver problemas dentro de un contexto.

Cuando separamos el patrón de diseño del contexto pueden aparecer los malentendidos y los problemas.

Por otra parte, el ser humano está cableado para ser perezoso. Esto quiere decir que de forma natural vamos a dar prioridad a aquellas acciones que supongan menos esfuerzo y ahorro de energía.

Por naturaleza, damos mayor prioridad a aquellas acciones que dan beneficios a corto plazo, aunque perjudiquen a largo plazo. Fumar o comer dulces es un buen ejemplo de ello. Es una cuestión de sistema de recompensas en nuestro cerebro que viene de serie con nosotros desde La Prehistoria.

Debido a esta cualidad de nuestro cerebro, somos especialmente hábiles en encontrar ciertos usos a herramientas que nos hagan la vida más fácil, aunque en ciertos contextos no sea lo más adecuado.

Los patrones de diseño han sido pervertidos debido a esta cualidad que traemos de serie. Quizás el patrón de diseño más pervertido de todos haya sido Singleton.

Incluso ha tenido el honor de formar parte del acrónimo STUPID, que reúne una serie de prácticas no recomendadas. La S se refiere al patrón de diseño Singleton.

Singleton

Singleton es un patrón de diseño que apareció por primera vez en el libro Design Patterns: Elements of Reusable Object-Oriented Software.

Este patrón surgió para resolver una limitación de los lenguajes de la época. Permite crearte una clase de la que solo puedes crear una única instancia.

Esta necesidad puede ser real en una aplicación y con los lenguajes no podíamos crear singletons de forma nativa, por eso surgió.

De hecho, en lenguajes modernos como Kotlin esta limitación no existe. En este lenguaje, mediante la palabra clave object resuelve el mismo problema que un Singleton. Debido a esto, el patrón Singleton no es necesario en Kotlin.

El libro de la banda de los 4 se publicó en 1994 y la primera versión de Kotlin estable fue lanzada en 2016.

¿De verdad crees que 12 años después Kotlin sacaría esta característica object si fuera un anti patrón?

¿Entonces qué es un anti patrón?

Siendo muy correcto con el lenguaje diría que nada.

Haciendo un símil de anti patrón con mala herramienta, ¿un cuchillo es una mala herramienta?, obviamente no.

¿Se puede usar mal? Obviamente sí. Un cuchillo puedes usarlo para cortar una manzana o para matar.

Es un cuchillo, una anti herramienta, no.

¿Singleton es un mal patrón y, por lo tanto, un anti patrón?, obviamente no.

¿Se puede usar Singleton mal? Obviamente sí.

El problema con el patrón Singleton ha sido el mal uso que se ha hecho de él. Debido a esa cualidad de nuestro cerebro a tratar de buscar gratificación a corto plazo, se empezó a popularizar el uso de Singleton para almacenar estado global en las aplicaciones.

¿Por qué se hacía esto?, porque ahorraba mucho trabajo a corto plazo, era muy cómodo hacerlo. Y ya sabes cómo le gusta esto a nuestro cerebro. Pero daba muchos dolores de cabeza a largo plazo.

El principal problema de almacenar estado global de una aplicación usando Singletons, es que acabas utilizando estos objetos a lo largo toda la aplicación, generando mucho acoplamiento y errores como memory leaks si aquello que almacenas dentro el framework puede hacer que deje de existir en algún momento. Por ejemplo, el contexto de una activity en Android.

Este acoplamiento trae a largo plazo muchos problemas de escalabilidad. Incluso a corto plazo trae problemas de testabilidad también, pero como la gente no suele escribir tests, ese problema no lo vieron venir.

Recuerda que escribir buenos tests hace que tu código sea testable y eso te pone en el camino de hacer tu código más fácil de cambiar en el futuro y, por lo tanto, más desacoplado.

Si queremos usar la palabra anti patrón deberíamos ampliar información indicando que nos referimos al mal uso de Singleton y no al patrón en si mismo.

Conclusiones

Existe confusión en torno a los desarrolladores de software sobre si un patrón de diseño es bueno o es malo y en consecuencia es un anti patrón de diseño.

Con este artículo he querido contribuir a desmitificar el uso de la palabra anti patrón sin aportar un contexto o más información.

En el curso de Clean Architecture vemos qué patrones de diseño son habituales utilizar con esta arquitectura. Puedes apuntarte a la lista de espera para la próxima edición en abierto

Curso Clean Architecture en abierto - Lista de Espera

¿Te ha gustado esta newsletter?

El mejor regalo de agradecimiento que me puedes hacer es compartirla 👇

Te animo a que que me des tu opinión, o me transmitas dudas en los comentarios de esta newsletter desde la web o respondiendo a este correo.

A veces tardo, pero siempre acabo contestando.