En Swift, la construction switch prend en charge un pattern matching avancé : vous pouvez utiliser where pour ajouter des conditions à chaque case. Cela permet de mettre en œuvre une logique métier complexe et un filtrage.
Exemple :
enum Person { case student(score: Int) case teacher(specialty: String) } let people = [Person.student(score: 95), Person.teacher(specialty: "Math"), Person.student(score: 65)] for person in people { switch person { case .student(let score) where score > 90: print("Élève excellent avec un score \(score)") case .teacher(let specialty): print("Professeur de la matière : \(specialty)") default: print("Autre cas") } }
L'utilisation de where améliore la lisibilité et évite la duplication de code, mais des conditions trop complexes peuvent nuire à la maintenabilité, et le pattern matching avec des valeurs associées nécessite un contrôle précis de l'ordre des cases.
Question : "Est-il obligatoire lors du pattern matching avec where dans switch d'utiliser des variables avec des noms uniques dans chaque case ?"
Réponse : Non, mais c'est recommandé pour éviter la confusion. Si vous utilisez les mêmes noms de variables dans différentes cases, le contexte sera limité à la case correspondante, mais le même nom peut nuire à la lisibilité et à la maintenance du code.
Exemple :
switch value { case .status(let code) where code == 200: print("OK") case .status(let code) where code == 404: print("Not found")
Histoire 1
Dans une application bancaire, il y avait une section d'analyse des statuts avec plusieurs conditions where. En raison d'un break manqué et d'un ordre incorrect des cases, une situation se produisait où un cas spécifique n'était pas traité, et les utilisateurs ne voyaient pas le statut complet des opérations. L'erreur n'a été détectée que lors des tests en production.
Histoire 2
Dans un système d'authentification, le développeur a utilisé les mêmes noms de variables dans différentes cases, ce qui a conduit à de la confusion et un bug : dans le second cas, on essayait d'utiliser une variable définie dans un autre case. La compilation fonctionnait, mais était incorrecte dans certains scénarios.
Histoire 3
Dans un pattern matching complexe avec where, on n'a pas pris en compte que le default ne traiterait pas certaines combinaisons d'enum associées, ce qui a fait planter l'application avec une erreur de pattern matching failed. Le problème n'a été remarqué qu'avec l'intégration de nouveaux types de données à l'avenir.