Typealias — définition, syntaxe et utilisation en Kotlin

Qu’est-ce que typealias ?

Typealias (alias de type) est une déclaration qui introduit un nom alternatif pour un type existant. Syntaxe : typealias NouveauNom = TypeExistant. Après la déclaration, NouveauNom peut être utilisé partout où TypeExistant est attendu — le compilateur les traite comme le même type. Au niveau du bytecode, typealias ne laisse aucune trace : toutes les informations d’alias sont effacées à la compilation.

Le but principal de typealias est d’améliorer la lisibilité du code. Au lieu d’une signature verbeuse fun process(callback: (Result) -> Unit), on peut écrire typealias Callback = (Result) -> Unit et utiliser Callback comme type de paramètre. Cela est particulièrement utile lorsque le même type fonctionnel se répète à plusieurs endroits dans le code : l’alias sert de point de définition unique et documente le but du type.

Typealias ne crée pas un nouveau type — ce n’est qu’un synonyme. Les variables de type Callback et (Result) -> Unit sont totalement interchangeables. Le compilateur ne génère pas d’erreur si une lambda est passée directement à une fonction qui attend Callback. Cela distingue typealias de l’inline class (value class), qui crée un nouveau type wrapper avec vérification à la compilation. Typealias est un renommage, pas un encapsulage.

Typealias pour les types fonctionnels

Le cas d’utilisation le plus courant de typealias en Kotlin concerne les types fonctionnels. Les longues signatures comme (Int, String) -> Boolean ou (List) -> Result rendent le code difficile à lire. Typealias les transforme en noms courts et significatifs qui documentent le but de la fonction : typealias Validator = (String) -> Boolean spécifie qu’il s’agit d’un validateur de chaînes.

// Without typealias
fun findUsers(
    filter: (List<User>) -> List<User>
): List<User>

// With typealias
typealias UserFilter = (List<User>) -> List<User>

fun findUsers(filter: UserFilter): List<User>

// Usage in class
typealias OnClickListener = (View) -> Unit

class Button {
    var onClick: OnClickListener = {}
}

Dans l’exemple, le typealias UserFilter cache le type fonctionnel complexe (List) -> List derrière un nom court. La signature de findUsers devient lisible : « accepte UserFilter, retourne List ». Le typealias OnClickListener fait ressembler le code à une déclaration d’interface mais sans la surcharge de créer une interface ou une classe abstraite séparée. Pendant ce temps, les lambdas et les fonctions anonymes continuent de fonctionner normalement — typealias ne nécessite aucune modification du code appelant.

Typealias avec les génériques

Typealias prend en charge les paramètres génériques, ce qui le rend encore plus flexible. On peut définir typealias Mapper = (T) -> R et l’utiliser avec n’importe quels types. Le compilateur substitue des types spécifiques aux paramètres à chaque utilisation de l’alias, préservant la sécurité totale des types.

// Generic typealias
typealias Mapper<T, R> = (T) -> R
typealias Provider<T> = () -> T
typealias ListTransformer<T> = (List<T>) -> List<T>

fun processNumbers(mapper: Mapper<Int, String>) {
    // mapper type is (Int) -> String
}

fun main() {
    val config: Provider<String> = { "default config" }
    val reverse: ListTransformer<Int> = { it.reversed() }
}

Dans la liste, Mapper est un alias générique pour toute transformation de T vers R. Provider est un fournisseur de valeur (une fabrique sans arguments). ListTransformer est une fonction de transformation de liste. Lors de l’appel de processNumbers(mapper: Mapper), le compilateur développe l’alias en (Int) -> String. Les génériques font de typealias un outil universel adapté à tout contexte sans dupliquer les déclarations.

Typealias pour les noms imbriqués et longs

Les classes imbriquées et les types paramétrés longs sont un autre domaine où typealias simplifie considérablement le code. Si une classe est profondément imbriquée dans une hiérarchie (Outer.Inner.Nested), la référencer par son nom complet encombre le code. Typealias raccourcit cet accès et le rend plus lisible. Cela est particulièrement pertinent pour les classes de bibliothèques tierces avec des noms longs.

// Alias for nested class
class NetworkResponse {
    class Error(val code: Int, val message: String)
}
typealias NetworkError = NetworkResponse.Error

// Alias for long library type
typealias UserId = Long
typealias JsonMap = Map<String, Any?>

fun process(error: NetworkError) {
    println("${error.code}: ${error.message}")
}

fun parseJson(data: JsonMap): UserId {
    return data["id"] as? Long ?: 0L
}

Dans l’exemple, NetworkError est un alias pour la classe imbriquée NetworkResponse.Error. En important le typealias, on peut utiliser NetworkError comme un type normal sans révéler la hiérarchie d’imbrication. JsonMap documente que la carte représente un objet JSON. UserId clarifie le but de Long dans un contexte spécifique — le lecteur comprend immédiatement qu’il s’agit d’un identifiant utilisateur, pas d’un nombre arbitraire. Cependant, typealias n’empêche pas de passer un Long simple là où UserId est attendu — pour cela, une value class est nécessaire.

Typealias vs Inline Class : différences

Typealias et inline class (value class) résolvent des problèmes différents, bien que tous deux introduisent un nouveau nom pour un type. Typealias n’est qu’un synonyme : une variable de type UserId = Long accepte n’importe quel Long sans vérification. Inline class encapsule une valeur dans un nouveau type qui est vérifié à la compilation : il est impossible de passer un Long simple là où une inline class UserId est attendue sans conversion explicite.

Le tableau montre la différence entre les deux mécanismes. Typealias convient pour les noms concis et la documentation du code lorsque le typage strict n’est pas nécessaire. L’inline class via le mot-clé value class (anciennement inline class) est nécessaire lorsqu’il est important de distinguer des valeurs sémantiquement différentes du même type primitif. Par exemple, UserId et OrderId sont tous deux des Long, mais passer l’un là où l’autre est attendu est une erreur logique que la value class prévient à la compilation.