¿Qué son los Patrones de Diseño?

Un patrón de diseño es una solución reutilizable a un problema que aparece una y otra vez al diseñar software — no un algoritmo (una receta exacta de pasos) ni una librería (código que se importa y usa tal cual), sino algo intermedio: una forma de estructurar clases y objetos que resuelve un problema recurrente, y que hay que adaptar a cada caso concreto. Nadie “instala” el patrón Observer; se implementa, con nombres y detalles propios de cada proyecto, siguiendo una forma general que ya se sabe que funciona.

Esa forma general no salió de la nada: en 1994, cuatro autores —conocidos desde entonces como la “Gang of Four” (GoF)— publicaron un catálogo de 23 patrones que habían observado repetirse en sistemas orientados a objetos bien diseñados. Ese catálogo, con ligeras variaciones, sigue siendo la referencia estándar hoy.

Por qué vale la pena conocerlos

• Son soluciones ya probadas. Cuando usás un patrón conocido, no estás inventando una solución nueva a un problema de diseño — estás aplicando algo que ya se validó en miles de proyectos distintos. Reduce el margen de error en decisiones que, mal tomadas, salen caras de revertir más adelante.
• Dan un vocabulario común. Decir “esto necesita un Strategy” comunica en tres palabras una intención de diseño completa a otro developer que conozca el catálogo. Sin ese vocabulario, la misma idea requiere explicar la estructura entera cada vez.
• Facilitan cambiar el código sin reescribirlo. La mayoría de los patrones existen para que un tipo de cambio futuro (agregar un nuevo tipo de producto, un nuevo formato de exportación, una nueva regla de negocio) se resuelva agregando código nuevo, no modificando el que ya funciona y ya fue probado.

No todos los problemas necesitan un patrón

Los patrones no son un objetivo en sí mismos. Meter un patrón donde no hace falta agrega indirección, archivos y capas que después alguien tiene que entender — a veces la solución más simple es directamente no usar ningún patrón. La señal correcta para reconocer cuándo aplicar uno no es “¿puedo usar un patrón acá?” sino “¿este problema concreto que tengo ya lo resolvió alguien de una forma reconocible?”. Los artículos de cada patrón incluyen una sección de cuándo conviene y cuándo no, justamente para eso.

Las tres categorías

El catálogo se organiza en tres grupos, según qué tipo de problema resuelven:

• Patrones creacionales — tienen que ver con cómo se crean los objetos, para no atar el código a clases concretas.
• Patrones estructurales — tienen que ver con cómo se combinan clases y objetos en estructuras más grandes, manteniéndolas flexibles y eficientes.
• Patrones de comportamiento — tienen que ver con cómo se reparten responsabilidades entre objetos y cómo se comunican entre sí.

El dominio de los ejemplos

Los ejemplos de código de este tema están en Java, y casi todos comparten un mismo caso ficticio: AndesShop, un e-commerce de indumentaria y equipo de trekking que va creciendo y se encuentra con problemas de diseño distintos a medida que suma funcionalidad.

AndesShop es el mismo negocio cuyo módulo de pagos usa como ejemplo el tema de arquitectura de software: allá se lo mira desde afuera, decidiendo boundaries, datos y comunicación entre servicios; acá se lo mira desde adentro de una clase. Es deliberado: los patrones de diseño y las decisiones de arquitectura operan sobre el mismo sistema, en escalas distintas.

Relación con los principios de diseño

Un patrón no es una alternativa a los principios de diseño, es una aplicación concreta de varios de ellos a la vez. Strategy es Open/Closed hecho estructura; Decorator es composición sobre herencia llevada al límite; casi todos empujan la dependencia hacia una abstracción, que es Inversión de Dependencias.

Por eso conviene leer los principios antes que el catálogo: los patrones se entienden mucho mejor cuando ya se sabe qué fuerza de diseño están resolviendo.