Patrones Gang of Four para sistemas reales: cómo usarlos sin sobreingeniería

El problema real no es recordar 23 nombres

Muchos equipos aprenden patrones como catálogo: Singleton, Factory, Strategy, Adapter. El problema es que después intentan reconocer el nombre antes de entender la presión de diseño.

En sistemas reales el orden debería ser inverso. Primero aparece una fuerza: reglas que cambian, integraciones que contaminan el dominio, objetos difíciles de construir, flujos que dependen de estado o consumidores que no deberían conocerse entre sí.

Las cuatro preguntas antes de aplicar un patrón

Uso patrones GoF solo cuando ayudan a cerrar una decisión de arquitectura:

• —¿Qué variabilidad necesito aislar para que el cambio no rompa todo?
• —¿Qué dependencia concreta quiero invertir o encapsular?
• —¿Qué parte del sistema necesita una interfaz estable?
• —¿Qué costo acepto a cambio de más flexibilidad?

Cómo se ve una decisión limpia

Un buen uso del patrón deja una decisión nombrada y defendible. No dice "usamos Strategy porque es elegante". Dice "las reglas de pricing cambian por segmento, entonces las aislamos como políticas reemplazables".

type PricingPolicy = { calculate(basePrice: number): number };

const founderDiscount: PricingPolicy = {
  calculate: (basePrice) => basePrice * 0.8,
};

const enterprisePricing: PricingPolicy = {
  calculate: (basePrice) => basePrice * 1.15,
};

Cuándo no usar patrones

Si el cambio todavía no existe, si el equipo no puede explicar el trade-off o si el patrón introduce más conceptos que el problema original, conviene esperar.

La sobreingeniería suele aparecer cuando se aplica un patrón para demostrar seniority, no para reducir riesgo. En una startup, esa complejidad se paga en onboarding, debugging y velocidad de aprendizaje.