Strategy Pattern: cuando el if/else empieza a dirigir el negocio

El problema real

El primer if no molesta. El décimo sí. Cuando pricing, permisos, scoring o validaciones cambian por segmento, el flujo principal empieza a acumular decisiones que nadie quiere tocar.

La señal de alerta es simple: para cambiar una regla de negocio hay que leer demasiado código que no representa esa regla.

Qué resuelve Strategy

Strategy define una interfaz común para varias políticas y permite elegir una en tiempo de ejecución. La decisión queda visible: qué política se usa y por qué.

No elimina la complejidad de negocio. La ubica en objetos chicos, testeables y reemplazables.

Cómo se ve en código

El checkout no necesita saber todos los casos. Solo necesita recibir una política con el contrato correcto.

type DiscountStrategy = {
  apply(total: number): number;
};

class Checkout {
  constructor(private readonly discount: DiscountStrategy) {}

  totalAfterDiscount(total: number) {
    return this.discount.apply(total);
  }
}

const noDiscount: DiscountStrategy = { apply: (total) => total };
const launchDiscount: DiscountStrategy = { apply: (total) => total * 0.9 };

Cuándo usarlo

Strategy tiene sentido cuando la variabilidad ya es real:

• —Reglas de pricing o descuentos cambian por segmento.
• —Hay validaciones alternativas para distintos canales.
• —Un cálculo tiene múltiples algoritmos intercambiables.
• —Necesitás testear reglas sin levantar todo el flujo principal.

Cuándo evitarlo

Si solo hay dos ramas estables y no hay evidencia de cambio, un condicional claro puede ser mejor. Strategy agrega nombres, archivos y composición; ese costo debe comprar flexibilidad real.