sealed class et interface en Kotlin — définition, syntaxe et application

Qu'est-ce que sealed class et sealed interface ?

sealed class est une classe abstraite avec une restriction : toutes ses sous-classes directes doivent être déclarées dans le même fichier que la classe sealed elle-même. Cette restriction rend la hiérarchie fermée (sealed) — aucun code en dehors du fichier ne peut ajouter une nouvelle sous-classe.

sealed interface, ajoutée dans Kotlin 1.5, offre la même garantie mais avec la flexibilité d'une interface : une interface sealed peut être implémentée par plusieurs classes, objets ou autres interfaces dans un fichier. Contrairement à sealed class, l'interface sealed n'a pas de restriction d'héritage unique — une classe peut implémenter plusieurs interfaces sealed à la fois.

Selon Kotlin Evolution and Roadmap (2026), l'interface sealed a été ajoutée à la demande de la communauté pour une modélisation plus flexible. La motivation principale est la capacité de combiner des hiérarchies de types indépendantes sans héritage multiple de classes.

Syntaxe de sealed class

La déclaration d'une classe sealed commence par le modificateur sealed avant class. Les sous-classes sont déclarées dans le même fichier.

sealed class NetworkResult {
    data class Success(val data: String) : NetworkResult()
    data class Error(val message: String) : NetworkResult()
    object Loading : NetworkResult()
}

Chaque sous-classe d'une classe sealed peut avoir ses propres propriétés et méthodes. Loading est un singleton (object), Success et Error sont des data classes avec paramètres. Le compilateur connaît les trois variantes et vérifie leur exhaustivité lorsqu'elles sont utilisées dans when.

Classes sealed imbriquées

Les classes sealed peuvent être imbriquées, créant des hiérarchies à plusieurs niveaux pour des modèles de données complexes sans perdre la sécurité de type.

sealed class UiState {
    object Idle : UiState()
    object Loading : UiState()
    data class Content(val items: List<Item>) : UiState()
    data class Error(val exception: Throwable) : UiState()
}

Syntaxe de sealed interface (Kotlin 1.5+)

sealed interface se déclare de manière similaire à sealed class, mais permet d'implémenter plusieurs interfaces sealed dans une seule classe.

sealed interface Action
sealed interface Loggable

data class Navigate(val route: String) : Action, Loggable
data class ShowToast(val text: String) : Action
object GoBack : Action, Loggable

La classe Navigate implémente deux interfaces sealed à la fois — Action et Loggable. C'est impossible avec sealed class en raison de la restriction d'héritage unique. L'interface sealed offre la flexibilité de combiner des hiérarchies indépendantes.

Quand choisir sealed interface plutôt que sealed class

sealed interface est préférable lorsque la hiérarchie ne nécessite pas d'état partagé ou de constructeur. Selon les JetBrains Kotlin Guidelines (2026), l'interface sealed doit être utilisée par défaut pour toutes les nouvelles hiérarchies où un constructeur commun n'est pas nécessaire, rendant le code plus flexible pour les extensions futures.

Traitement exhaustif dans when

Le principal avantage des types sealed est le traitement exhaustif dans l'expression when. Le compilateur vérifie que toutes les sous-classes possibles sont couvertes.

fun handleResult(result: NetworkResult): String = when (result) {
    is NetworkResult.Success -> "Data: ${result.data}"
    is NetworkResult.Error -> "Error: ${result.message}"
    is NetworkResult.Loading -> "Loading..."
    // else n'est pas requis — le compilateur sait que toutes les variantes sont couvertes
}

Si un développeur ajoute une nouvelle sous-classe à une hiérarchie sealed mais oublie de la traiter dans when — le compilateur générera une erreur. C'est de la sécurité au niveau des types, indisponible avec les hiérarchies ouvertes utilisant une branche else.

Selon Google Android Developers (2026), les classes sealed sont la méthode recommandée pour modéliser l'état de l'UI dans Jetpack Compose. La vérification exhaustive de when empêche les états où le développeur n'a pas traité toutes les variantes possibles d'affichage d'un écran.

Comparaison sealed class avec enum class

enum class et sealed class sont souvent confondues, mais elles ont des objectifs et des capacités différents.

Le choix entre sealed class et enum class dépend de la tâche. Si les variantes ne portent pas de données supplémentaires — utilisez enum. Si chaque variante contient des champs uniques — utilisez sealed class ou sealed interface.

Scénarios pratiques d'utilisation

Les types sealed sont utilisés dans les projets Kotlin pour une série de scénarios standard où une modélisation type-safe est nécessaire.

État de l'UI dans Jetpack Compose

Chaque écran Compose peut avoir une classe sealed UiState décrivant tous les états possibles : Idle, Loading, Content(data), Error(exception). L'expression when garantit que tous les états sont traités.

Résultats de requêtes réseau

NetworkResult avec les variantes Success, Error, Loading est un modèle standard dans les projets Kotlin avec Retrofit et Ktor. La classe sealed assure un traitement sûr de chaque résultat de requête.

Navigation dans les projets multi-modules

sealed interface pour les routes de navigation permet aux modules de déclarer leurs propres routes tout en restant dans une hiérarchie unifiée. Cela élimine les erreurs de routes inconnues à la compilation.

Selon KotlinConf (2025), sealed class et sealed interface sont la base de la conception type-safe dans les applications Kotlin modernes. Elles se combinent avec data class pour modéliser des structures de domaine complexes sans perdre la sécurité à la compilation.