Adiós al Caos: Cómo Refactorizar IF-ELSE Complejos usando Object Mapping

Este fenómeno se conoce como Spaghetti Code y es el enemigo número uno de la escalabilidad. Hoy vamos a ver cómo transformar esa lógica en estructuras limpias, mantenibles y profesionales usando Object Literals y Mapas.

---

1. El Problema: El "Efecto Cascada"

Cuando usas múltiples if-else, el motor de JavaScript evalúa cada línea secuencialmente. Si la condición que buscas es la última, el programa desperdicia recursos evaluando todas las anteriores. Además, la legibilidad se vuelve nula.

// ❌ Código difícil de mantener y escalar
function procesarNotificacion(tipo) {
  if (tipo === 'email') {
    enviarEmail();
  } else if (tipo === 'sms') {
    enviarSMS();
  } else if (tipo === 'push') {
    enviarPush();
  } else {
    logError();
  }
}

---

2. Nivel 1: El Patrón Lookup (Básico)

La forma más sencilla de limpiar esto es crear un objeto donde las llaves sean tu condición y los valores el resultado o la función a ejecutar.

// ✅ Código limpio y directo
const NOTIFICACIONES = {
  email: enviarEmail,
  sms: enviarSMS,
  push: enviarPush
};

function procesarNotificacion(tipo) {
  // Usamos el cortocircuito || para definir un caso por defecto
  const accion = NOTIFICACIONES[tipo] || logError;
  return accion();
}

---

3. Nivel 2: Resolviendo Problemas Complejos

Aquí es donde la técnica se vuelve realmente potente para aplicaciones reales, especialmente en el desarrollo Frontend.

A. Manejo de Estados de UI (Ideal para React)

En lugar de llenar tu componente de ternarios o if antes del return, mapea tus componentes de estado. Esto separa la lógica de negocio de la visualización.

const UserProfileViews = {
  LOADING: () => <Skeleton />,
  ERROR: ({ message }) => <ErrorMessage text={message} />,
  SUCCESS: ({ data }) => <UserCard user={data} />,
  EMPTY: () => <EmptyState />
};

const UserProfile = ({ status, payload }) => {
  // Elegimos el componente según el estado del servidor
  const Component = UserProfileViews[status] || UserProfileViews.ERROR;
  
  return (
    <div className="container">
      <Component {...payload} />
    </div>
  );
};

B. Lógica de Rangos y Condiciones Dinámicas

A veces los if comparan rangos (ej: precio > 100). Para esto, usamos un Array de Criterios con funciones de validación que nos permiten mantener la estructura organizada:

const REGLAS_DESCUENTO = [
  { test: (val) => val > 500,  apply: (val) => val * 0.80 }, // 20% OFF
  { test: (val) => val > 100,  apply: (val) => val * 0.90 }, // 10% OFF
  { test: (val) => true,       apply: (val) => val }         // Sin descuento
];

const calcularPrecio = (monto) => {
  // Buscamos la primera regla que se cumpla de forma declarativa
  const regla = REGLAS_DESCUENTO.find(r => r.test(monto));
  return regla.apply(monto);
};

---

4. ¿Por qué este enfoque es superior?

1. Complejidad Constante $O(1)$: En accesos directos por llave, la velocidad es máxima. No importa si tenés 10 o 100 casos, no hay degradación de performance.
2. Principio de Responsabilidad Única: Podés extraer las configuraciones a archivos externos, manteniendo tus componentes y funciones principales extremadamente limpios.
3. Open/Closed Principle: Si necesitás agregar un nuevo tipo de notificación o regla, no tocás la función lógica, simplemente extendés el objeto o array de configuración.

Conclusión

Refactorizar no se trata solo de estética; se trata de reducir la carga cognitiva para el equipo. Un código basado en mapas es más predecible, más fácil de testear y mucho más profesional. La próxima vez que sientas la tentación de escribir el cuarto else if, detenete y pensá: ¿Podría esto ser un objeto?