En Swift, la estructura switch admite pattern matching avanzado: puedes usar where para agregar condiciones a casos individuales. Esto permite implementar lógica de negocio compleja y filtrado.
Ejemplo:
enum Person { case student(score: Int) case teacher(specialty: String) } let people = [Person.student(score: 95), Person.teacher(specialty: "Matemáticas"), Person.student(score: 65)] for person in people { switch person { case .student(let score) where score > 90: print("Estudioso con resultado \(score)") case .teacher(let specialty): print("Profesor de la materia: \(specialty)") default: print("Otro caso") } }
El uso de where mejora la legibilidad y evita la duplicación de código, pero condiciones demasiado complejas pueden dificultar el mantenimiento, y el pattern matching con valores asociados requiere un control claro del orden de los casos.
Pregunta: "¿Es necesario que al hacer pattern matching con where dentro de switch se llamen las variables con nombres únicos en cada caso?"
Respuesta: No, pero se recomienda para evitar confusiones. Si se utilizan los mismos nombres de variables en diferentes casos, el contexto se limitará al caso correspondiente, pero el mismo nombre puede obstaculizar la legibilidad y el mantenimiento del código.
Ejemplo:
switch value { case .status(let code) where code == 200: print("OK") case .status(let code) where code == 404: print("No encontrado")
Historia 1
En una aplicación bancaria hubo una sección de análisis de estados con múltiples condiciones where. Debido a un break omitido y un orden incorrecto de los casos, se produjo una situación en la que no se manejaba un caso específico, y los usuarios no veían el estado completo de las operaciones. El error fue descubierto solo durante las pruebas en campo.
Historia 2
En el sistema de autorización, un desarrollador utilizó los mismos nombres de variables en diferentes casos, lo que llevó a confusiones y un error: en el segundo caso intentaron utilizar una variable definida en otro caso. La compilación funcionó, pero incorrectamente en ciertos escenarios.
Historia 3
En un pattern matching complejo con where no se consideró que el default no manejaría parte de las combinaciones del enum asociado, lo que provocó que la aplicación fallara con un error de pattern matching failed. El problema fue notado solo al integrar nuevos tipos de datos en el futuro.