Réponse

typealias en Kotlin est un mécanisme pour déclarer un nom alternatif pour un type existant (classe, interface, fonction, type générique, etc.). Utilisé pour :

• Améliorer la lisibilité des types complexes et imbriqués
• Cacher les spécificités de l'implémentation
• Faciliter la compatibilité lors de la transition entre les versions de l'API

Limitations :

• typealias ne crée pas un nouveau type, mais seulement un deuxième nom (synonyme), donc le compilateur ne les distingue pas lors de la typage.
• typealias ne peut pas être utilisé pour ajouter de nouvelles fonctionnalités.
• Les alias ne peuvent être déclarés qu'au niveau du fichier, en dehors des classes/des fonctions.

Exemple d'application :

typealias ClickHandler = (View, MotionEvent) -> Unit

fun setClickHandler(handler: ClickHandler) {
    // ...
}

val handler: ClickHandler = { view, event ->
    // Logique de gestion
}

Support et lisibilité :

• Améliore la clarté de l'API, lorsque le type de la fonction est trop complexe.
• Permet une migration flexible entre les implémentations internes tout en restant compatible avec les clients externes.

Question piège

Question : "Les typealias en Kotlin sont-ils de nouveaux types du point de vue du compilateur et peuvent-ils être utilisés pour restreindre la valeur des variables ?"

Réponse : Non, les typealias ne sont que des synonymes de type. Ils ne forment pas un nouveau type et ne fournissent aucune vérification supplémentaire au moment de la compilation. Toutes les fonctions, variables et paramètres de type typealias sont du même type de base.

Exemple :

typealias UserId = String
typealias Email = String

fun process(id: UserId) {}
fun process(email: Email) {}

process("abc@def.com") // Pas d'erreur — pas de distinction !

Exemples d'erreurs réelles en raison d'une méconnaissance des subtilités du sujet

---

Histoire

Utilisation de typealias pour les identifiants de différentes entités (UserId, OrderId), supposant que le compilateur les distinguerait, mais en réalité, ils ont passé des valeurs l'un à l'autre sans erreurs de compilation, entraînant une confusion de logique et des bogues.

---

Histoire

Lors de la migration d'une ancienne API, des typealias ont été assignés à des expressions lambda complexes, mais la documentation n'a pas indiqué de nouvelles définitions. Résultat — les programmeurs ne comprenaient pas ce que signifiait l'alias (par exemple, Loader), et l'ont utilisé incorrectement, ce qui a conduit à des erreurs d'exécution.

---

Histoire

Dans un des projets, typealias ViewClickHandler a été redéfini dans différents fichiers avec des signatures différentes, en pensant que les alias seraient liés globalement. Au final — lors de la génération automatique de documentation, il y avait des duplications, et lors de la compilation, un conflit de noms est survenu.