Qu'est-ce qu'une "sealed class" en Kotlin et comment simplifient-elles le traitement des états ? Comment les sealed classes sont-elles liées à l'expression when et pourquoi est-ce important pour la sécurité des types ? Donnez un exemple d'utilisation.

Réponse

sealed class en Kotlin est une classe abstraite qui limite l'héritage : tous les sous-types doivent être déclarés dans un seul fichier. Cela est pratique pour les hiérarchies où l'ensemble des variantes est fixe (par exemple, pour décrire des états, des événements ou des erreurs) :

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

fun handle(result: Result) = when (result) {
    is Result.Success -> print("Succès!")
    is Result.Error -> println("Erreur : ${result.message}")
    is Result.Loading -> println("Chargement...")
}

Lien avec when : Si nous utilisons tous les sous-types de sealed class dans l'expression when, le compilateur vérifie l'exhaustivité (analyse complète des variantes). Cela garantit qu'en ajoutant un nouvel état, le développeur obtiendra une erreur de compilation s'il ne traite pas la nouvelle variante.

Pourquoi c'est important :

• Simplifie le maintien de la sécurité des types.
• Indépendance vis-à-vis des vérifications à l'exécution, le traitement a lieu au moment de la compilation.
• Force à considérer explicitement toutes les variantes de la hiérarchie.

---

Question piège

"Peut-on placer les sous-types de sealed class dans différents fichiers ou paquets ? Comment cela influence-t-il la sécurité des types ?"

Réponse : Non, tous les sous-types directs de sealed class doivent être définis dans un seul fichier. C'est un contrôle du compilateur pour garantir la sécurité des types. Si les sous-types sont placés dans d'autres fichiers de paquets, le compilateur déclenchera une erreur.

---

Exemples d'erreurs réelles dues à une méconnaissance des subtilités du sujet

---

Histoire

Lors de la conception de la logique métier des paiements, des variantes de résultats d'opération ont été ajoutées, oubliant de mettre à jour l'expression when. Mais grâce à sealed class, le compilateur a mis en évidence les cas non pris en compte. Dans un autre projet en Java, ce scénario aurait conduit à l'introduction d'un statut non initialisé dans le produit.

---

Histoire

Dans le projet, après la migration de certaines données de sealed class vers des open class, les vérifications when exhaustives ont cessé de fonctionner — de nouveaux états ont commencé à "se perdre" dans la logique de traitement, ce qui a causé un comportement incorrect de l'interface.

---

Histoire

Dans un système de e-commerce, une tentative d'optimisation de l'architecture en déplaçant les sous-types de sealed class dans des fichiers séparés (chacun dans son propre module pour réutilisation) a rompu la compilation et a nécessité un refactoring urgent avant la sortie.