¡Remplaza el Switch ya!
El desarrollo ágil se basa en ciclos iterativos y entregas incrementales, permitiendo flexibilidad y mejoras continuas, asegurando una mayor satisfacción del cliente
Cuando comenzamos a programar, el switch suele ser una de las primeras estructuras de control que aprendemos. Es fácil de entender: un conjunto de condiciones organizadas que nos ayudan a manejar diferentes casos. Sin embargo, a medida que nuestros proyectos crecen y los requisitos se vuelven más complejos, este enfoque puede empezar a jugar en nuestra contra.
El switch funciona bien para manejar un número limitado de opciones, pero ¿qué pasa cuando los casos empiezan a multiplicarse? De repente, ese bloque de código sencillo se transforma en un volumen difícil de leer y mantener. Además, si tu proyecto requiere actualizaciones frecuentes o ajustes dinámicos, el switch no es la herramienta más flexible
¿Que problemas vemos y que alternativas consideramos a tener en cuenta?
Los problemas del switch
Imagina que estás desarrollando una aplicación con un proceso por pasos, y necesitas mostrar diferentes mensajes según el paso en el que se encuentre el usuario. La solución tradicional sería usar un switch. Aunque funcional, este enfoque puede llevar a varios problemas:
- Dificultad para mantener el código: Si necesitas agregar o modificar casos, cada cambio implica tocar la estructura directamente, aumentando el riesgo de cometer errores.
- Falta de claridad: Un switch con muchos casos puede parecer interminable y dificultar que otros (o incluso tú mismo, dentro de unas semanas) entiendan rápidamente qué está haciendo el código.
- Rígido ante cambios dinámicos: Si los mensajes dependen de datos externos o necesitan cambiarse frecuentemente, el switch no se adapta bien
Una alternativa: Mapear casos en un objeto
Aquí es donde los objetos entran al rescate. En lugar de usar un switch, puedes crear un objeto donde cada caso esté mapeado como un par clave-valor. Este enfoque es más limpio, legible y escalable, y permite mantener la lógica separada de la estructura.
Vamos a verlo en acción.
Ejemplo 1: Usando un switch
tsx
Copiar código
const renderStep = (step: number): string => {
switch (step) {
case 0:
return "Paso 1: Introducir datos";
case 1:
return "Paso 2: Confirmar información";
case 2:
return "Paso 3: Finalizar";
default:
return "Error: Paso no válido";
}
};
Este código cumple su función, pero imagina que el proceso crece a 10, 20 o incluso más pasos. La estructura rápidamente se vuelve poco manejable. Además, si necesitas cambiar un mensaje o agregar un nuevo paso, tendrás que modificar directamente el bloque del switch.
Ejemplo 2: Usando un objeto
tsx
Copiar código
const stepMessages: Record<number, string> = {
0: "Paso 1: Introducir datos",
1: "Paso 2: Confirmar información",
2: "Paso 3: Finalizar",
};
const renderStep = (step: number): string => {
return stepMessages[step] ?? "Error: Paso no válido";
};
Con este enfoque, las claves del objeto representan cada paso, y los valores contienen los mensajes correspondientes. Si necesitas agregar o cambiar algo, solo tienes que modificar el objeto sin preocuparte de la lógica principal.
Conclusión: ¿Por qué el enfoque con objetos es mejor?
- Mayor claridad: La estructura de los casos es más sencilla de leer. No necesitas recorrer un switch para entender qué hace cada paso.
- Fácil mantenimiento: Agregar, eliminar o modificar un caso es tan simple como ajustar una clave o valor en el objeto.
- Reutilización: Puedes usar el mismo objeto en diferentes partes del código. Por ejemplo, si tienes que mostrar los mensajes en otro lugar, solo tienes que importar el objeto.
- Escalabilidad: Este enfoque se adapta mejor si los casos son dinámicos o necesitan actualizarse desde una fuente externa.
El switch cumple su función, pero no escala bien en proyectos complejos. Usar un objeto ofrece una solución más limpia, clara y fácil de mantener. Simplifica el código desde el inicio.