typealias en Swift permet de définir un nom alternatif pour un type existant. Cela peut être utile pour simplifier des types longs ou complexes, par exemple, lorsqu'on travaille avec des types de closure ou des generics. L'utilisation de typealias améliore la lisibilité du code et facilite sa maintenance, surtout lorsque les types changent souvent ou sont utilisés à plusieurs endroits.
Par exemple, si vous rencontrez souvent une closure de ce type :
(type: String, completion: (Result<Bool, Error>) -> Void) -> Void
Vous pouvez le remplacer par :
typealias FetchCompletion = (Result<Bool, Error>) -> Void typealias FetchHandler = (String, FetchCompletion) -> Void
Cela augmentera considérablement la lisibilité des signatures de méthodes et d'interfaces.
Lors de l'utilisation de typealias dans des architectures complexes, il faut maintenir un équilibre : un abus peut rendre la navigation dans le code complexe, et un chevauchement de noms avec des types existants peut entraîner des conflits et entraîner des malentendus.
Peut-on créer un nouveau type indépendant ou modifier le comportement d'un type existant avec typealias ?
Réponse : Non, typealias ne crée qu'un nom alternatif pour un type existant, sans ajouter de nouvelles fonctionnalités ni modifier son comportement. Par exemple :
typealias UserID = String let id: UserID = "123" let str: String = id // Correct : UserID et String - c'est le même type
UserID et String sont en réalité complètement interchangeables, ce n'est pas un nouveau type.
Histoire
Dans un grand projet, on a commencé à utiliser typealias pour différents identifiants : typealias UserID = String, typealias ProductID = String. Dans l'un des méthodes de service, on a par erreur passé ProductID en argument, s'attendant à UserID, et cela n'a pas été détecté ni à la compilation ni dans les tests, ce qui a plus tard conduit à une rupture d'intégrité des données.
Histoire
L'utilisation de longues chaînes de typealias dans des protocoles a conduit à de la confusion lors de la lecture des API publiques : typealias Output = Result<Bool, MyError>, typealias ServiceResult = Output. Un nouveau développeur a à tort supposé qu'il s'agissait de types différents et a mal implémenté la gestion des erreurs.
Histoire
Dans un module existant, un typealias a été déclaré avec un nom identique à un type utilisateur dans un framework dépendant. Cela a entraîné un conflit et une ambiguïté dans la résolution de type, qui n'a pu être décelée qu'à l'assemblage et à la charge des dépendances, rendant la recherche et la résolution du bug plus complexes.