sealed class und interface in Kotlin — was es ist, Syntax und Anwendung

Was sind sealed class und sealed interface?

sealed class ist eine abstrakte Klasse mit einer Einschränkung: Alle ihre direkten Unterklassen müssen in derselben Datei wie die sealed-Klasse selbst deklariert werden. Diese Einschränkung macht die Hierarchie geschlossen (sealed) — kein Code außerhalb der Datei kann eine neue Unterklasse hinzufügen.

sealed interface, hinzugefügt in Kotlin 1.5, bietet dieselbe Garantie, aber mit der Flexibilität eines Interfaces: Ein sealed interface kann von mehreren Klassen, Objekten oder anderen Interfaces in einer Datei implementiert werden. Im Gegensatz zu sealed class hat sealed interface keine Einfachvererbungsbeschränkung — eine Klasse kann mehrere sealed-Interfaces gleichzeitig implementieren.

Laut Kotlin Evolution and Roadmap (2026) wurde sealed interface auf Anfrage der Community für flexiblere Modellierung hinzugefügt. Die Hauptmotivation ist die Möglichkeit, unabhängige Typhierarchien ohne Mehrfachvererbung von Klassen zu kombinieren.

Syntax der sealed class

Die Deklaration einer sealed class beginnt mit dem Modifikator sealed vor class. Unterklassen werden in derselben Datei deklariert.

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

Jede Unterklasse einer sealed class kann eigene Eigenschaften und Methoden haben. Loading ist ein Singleton (object), Success und Error sind data classes mit Parametern. Der Compiler kennt alle drei Varianten und prüft ihre Vollständigkeit bei Verwendung in when.

Verschachtelte sealed-Klassen

Sealed-Klassen können verschachtelt werden, wodurch mehrstufige Hierarchien für komplexe Datenmodelle ohne Verlust der Typsicherheit entstehen.

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

Syntax des sealed interface (Kotlin 1.5+)

sealed interface wird ähnlich wie sealed class deklariert, erlaubt jedoch die Implementierung mehrerer sealed-Interfaces in einer Klasse.

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

Die Klasse Navigate implementiert zwei sealed-Interfaces gleichzeitig — Action und Loggable. Dies ist mit sealed class aufgrund der Einfachvererbungsbeschränkung unmöglich. sealed interface bietet die Flexibilität, unabhängige Hierarchien zu kombinieren.

Wann sealed interface statt sealed class wählen

sealed interface ist vorzuziehen, wenn die Hierarchie keinen gemeinsamen Zustand oder Konstruktor erfordert. Laut den JetBrains Kotlin Guidelines (2026) sollte sealed interface standardmäßig für alle neuen Hierarchien verwendet werden, bei denen kein gemeinsamer Konstruktor benötigt wird, was den Code flexibler für zukünftige Erweiterungen macht.

Erschöpfende Behandlung in when

Der Hauptvorteil von sealed-Typen ist die erschöpfende (exhaustive) Behandlung im when-Ausdruck. Der Compiler prüft, ob alle möglichen Unterklassen abgedeckt sind.

fun handleResult(result: NetworkResult): String = when (result) {
    is NetworkResult.Success -> "Data: ${result.data}"
    is NetworkResult.Error -> "Error: ${result.message}"
    is NetworkResult.Loading -> "Loading..."
    // else ist nicht erforderlich — der Compiler weiß, dass alle Varianten abgedeckt sind
}

Wenn ein Entwickler eine neue Unterklasse zu einer sealed-Hierarchie hinzufügt, aber vergisst, sie in when zu behandeln, gibt der Compiler einen Fehler aus. Dies ist Sicherheit auf Typebene, die bei offenen Hierarchien mit else-Zweig nicht verfügbar ist.

Laut Google Android Developers (2026) sind sealed-Klassen die empfohlene Methode zur Modellierung des UI-Zustands in Jetpack Compose. Die erschöpfende when-Prüfung verhindert Zustände, bei denen der Entwickler nicht alle möglichen Anzeigevarianten eines Bildschirms behandelt hat.

Vergleich sealed class mit enum class

enum class und sealed class werden oft verwechselt, haben aber unterschiedliche Zwecke und Fähigkeiten.

Die Wahl zwischen sealed class und enum class hängt von der Aufgabe ab. Wenn Varianten keine zusätzlichen Daten tragen — verwenden Sie enum. Wenn jede Variante eindeutige Felder enthält — verwenden Sie sealed class oder sealed interface.

Praktische Anwendungsszenarien

Sealed-Typen werden in Kotlin-Projekten für eine Reihe von Standardszenarien verwendet, bei denen typsichere Modellierung erforderlich ist.

UI-Zustand in Jetpack Compose

Jeder Compose-Bildschirm kann eine sealed class UiState haben, die alle möglichen Zustände beschreibt: Idle, Loading, Content(data), Error(exception). Der when-Ausdruck garantiert, dass alle Zustände behandelt werden.

Ergebnisse von Netzwerkanfragen

NetworkResult mit den Varianten Success, Error, Loading ist ein Standardmuster in Kotlin-Projekten mit Retrofit und Ktor. sealed class gewährleistet eine sichere Behandlung jedes Anforderungsergebnisses.

Navigation in Multi-Modul-Projekten

sealed interface für Navigationsrouten ermöglicht es Modulen, ihre eigenen Routen zu deklarieren, während sie innerhalb einer einheitlichen Hierarchie bleiben. Dies eliminiert Fehler mit unbekannten Routen zur Kompilierzeit.

Laut KotlinConf (2025) sind sealed class und sealed interface die Grundlage für typsicheres Design in modernen Kotlin-Anwendungen. Sie werden mit data class kombiniert, um komplexe Domänenstrukturen zu modellieren, ohne die Sicherheit zur Kompilierzeit zu verlieren.