Le pattern matching en Swift permet d'extraire des valeurs de manière élégante et de les comparer à des modèles dans les conditions switch, les boucles et les opérateurs if case. La caractéristique clé est la possibilité non seulement de comparer des valeurs, mais aussi d'extraire des données associées à partir de structures complexes, par exemple, des énumérations avec des valeurs associées, des optionnels ou des tuples.
L'opérateur case let est souvent utilisé pour extraire des valeurs imbriquées, par exemple :
enum Result { case success(value: Int) case failure(error: Error) } let result: Result = .success(value: 42) switch result { case .success(let value): print("Success with value \(value)") case .failure(let error): print("Failed with error: \(error)") }
Il est également pratique d'appliquer le pattern matching lors du travail avec des collections :
let items: [Result] = [.success(value: 1), .failure(error: MyError()), .success(value: 42)] for case let .success(value) in items { print("Found value: \(value)") }
Il est important de se rappeler que tous les modèles ne fonctionneront pas si la structure ou l'énumération est définie sans valeurs associées ou sans le support nécessaire d'Equatable. De plus, les développeurs inexpérimentés peuvent se tromper sur l'exhaustivité (la considération de tous les cas d'énumération).
Quelle est la différence entre if let, guard let et if case let lors du travail avec des valeurs optionnelles? Dans quels cas chacun d'eux est-il préférable?
Réponse :
if let et guard let sont utilisés pour extraire des valeurs de manière sécurisée à partir d'optionnels.if case let s'applique non seulement aux optionnels, mais aussi aux énumérations avec des valeurs associées, élargissant les possibilités de pattern matching.Exemple :
let number: Int? = 42 if case let value? = number { print("Value is \(value)") }
value? - modèle qui extrait la valeur uniquement si elle n'est pas nil.
Histoire
Un développeur n'a pas implémenté tous les cas pour une énumération dans un switch. L'ajout d'un nouveau cas à l'énumération a conduit à une erreur silencieuse, car la branche par défaut avait été ajoutée "pour la sécurité". En conséquence, une partie de la logique a cessé de fonctionner, et l'erreur n'est apparue que chez l'utilisateur.
Histoire
Dans un projet, un tableau
Result<T, Error>a été utilisé et on a essayé de filtrer uniquement les valeurs réussies à travers une bouclefor x in.... Cela a conduit à une vérification manuelle du type, ce qui a causé le passage à côté de certaines réussites en raison d'une erreur dans la condition.
Histoire
Un des membres de l'équipe ne savait pas à propos de
if case letavec des optionnels et a toujours fait une double vérification : d'abordif number != nil, puis extraction forcée via "force unwrap". Cela a conduit à des crashs en production.