Patrones de diseño explicados con ejemplos prácticos

Es una solución ya probada a un problema de estructura que aparece una y otra vez en el software, descrita de forma general para poder reconocerla y reaplicarla en distintos contextos. No es una biblioteca ni código listo para copiar y pegar, sino una plantilla de organización que se adapta a cada caso concreto. Su valor es doble. Por un lado, aporta estructura reutilizable: evita reinventar la forma de resolver algo que muchas personas ya resolvieron bien a lo largo de los años. Por otro, y quizás más importante, aporta un vocabulario compartido: poder decir que en cierta parte se usa un observador o una estrategia comunica a otro programador una estructura entera en una sola palabra, sin necesidad de explicar los detalles. Ese lenguaje común es, para muchos, el mayor beneficio de conocer los patrones.

Los patrones clásicos se agrupan en tres familias según qué tipo de problema resuelven. Los patrones de creación se ocupan de cómo se crean los objetos, e incluyen el singleton, que garantiza una única instancia compartida, y el factory, que centraliza la decisión de qué objeto concreto crear. Los patrones estructurales se ocupan de cómo se componen los objetos entre sí, e incluyen el adaptador, que hace que piezas con interfaces incompatibles trabajen juntas, y el decorador, que agrega comportamiento envolviendo un objeto sin modificarlo. Y los patrones de comportamiento se ocupan de cómo se comunican y actúan los objetos, e incluyen la estrategia, que permite intercambiar algoritmos, y el observador, que avisa automáticamente a varias partes cuando algo cambia. No hace falta memorizarlos todos: conviene entender el problema que resuelve cada uno para reconocerlo cuando aparezca.

Cuando aparece de verdad el problema que ese patrón resuelve, y no antes. La regla de oro es contraintuitiva respecto de la tentación natural: no hay que salir a buscar dónde aplicar un patrón recién aprendido, sino esperar a que el código empiece a doler de una forma concreta que un patrón conocido alivia, y reconocer entonces cuál encaja. Los patrones son un destino al que se llega, no un punto de partida desde el que se construye. Por ejemplo, el patrón de estrategia tiene sentido cuando ya tenés varias formas de calcular lo mismo y el código se está llenando de condiciones para elegir entre ellas; aplicarlo antes, cuando hay una sola forma, solo agrega estructura innecesaria. Primero el problema, después el patrón: ese orden es lo que distingue el buen uso del sobrediseño.

Porque un patrón metido donde no existe el problema que resuelve no simplifica nada: al contrario, agrega estructura, capas de abstracción y nombres nuevos que quien lea el código tendrá que entender, todo para resolver un problema que no se tenía. El resultado es código más difícil de leer y mantener, justo lo opuesto a la meta de los patrones. Es un error especialmente común en quien acaba de aprenderlos, porque genera la tendencia a ver oportunidades de aplicarlos por todas partes, metiendo una fábrica para crear una sola clase o un singleton para algo que no necesita ser único. La solución más simple que funciona casi siempre es la mejor, y agregar un patrón debe justificarse por un beneficio real y presente, no por la satisfacción de usar una técnica conocida o por una necesidad futura imaginada que quizás nunca llegue.

Los patrones como conceptos son en gran medida independientes del lenguaje, porque describen formas de organizar el código para resolver problemas de estructura que aparecen en muchos lenguajes distintos. Dicho esto, la forma concreta de implementarlos y su utilidad varían según las características de cada lenguaje. Algunos patrones que son muy necesarios en lenguajes rígidos resultan triviales o innecesarios en lenguajes más flexibles, porque el propio lenguaje ya ofrece de forma nativa lo que el patrón lograba a mano. Por ejemplo, en lenguajes donde las funciones se pueden pasar como valores, el patrón de estrategia se vuelve casi transparente. Por eso conviene entender el problema que cada patrón resuelve más que memorizar su implementación en un lenguaje: así se reconoce cuándo el lenguaje ya lo resuelve solo y cuándo hace falta aplicarlo explícitamente.

Conocer los patrones más comunes y, sobre todo, entender el vocabulario asociado es muy valioso, porque aparece en entrevistas, en la lectura de código ajeno y en las conversaciones de equipo, donde nombrar un patrón es una forma rápida de comunicar una estructura. Pero es más importante entender el problema que cada uno resuelve y saber cuándo aplicarlo con criterio que memorizar una lista de definiciones. Quien recita patrones pero los fuerza en todos lados es un problema mayor que quien conoce pocos pero escribe código simple y claro. La recomendación práctica es aprenderlos después de tener una base sólida de fundamentos y de código limpio, reconociendo los más frecuentes en proyectos reales, y dejar el estudio exhaustivo del catálogo completo para cuando ya se tenga experiencia suficiente para juzgar cuándo cada uno aporta de verdad.