sealed class en interface in Kotlin — wat is het, syntaxis en toepassing

Wat zijn sealed class en sealed interface?

sealed class is een abstracte klasse met een beperking: al zijn directe subklassen moeten in hetzelfde bestand als de sealed class worden gedeclareerd. Deze beperking maakt de hiërarchie gesloten (sealed) — geen code buiten het bestand kan een nieuwe subklasse toevoegen.

sealed interface, toegevoegd in Kotlin 1.5, biedt dezelfde garantie met de flexibiliteit van een interface: sealed interface kan worden geïmplementeerd door meerdere klassen, objecten of andere interfaces in één bestand. In tegenstelling tot sealed class heeft sealed interface geen beperking voor enkelvoudige overerving — een klasse kan meerdere sealed interfaces tegelijk implementeren.

Volgens Kotlin Evolution and Roadmap (2026) is sealed interface toegevoegd op verzoek van de community voor flexibelere modellering. De belangrijkste motivatie was de mogelijkheid om onafhankelijke typehiërarchieën te combineren zonder meervoudige klasse-overerving.

Syntaxis van sealed class

Declaratie van een sealed class begint met de modifier sealed voor class. Subklassen worden in hetzelfde bestand gedeclareerd.

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

Elke subklasse van een sealed class kan eigen eigenschappen en methoden hebben. Loading is een singleton (object), Success en Error zijn data class met parameters. De compiler kent alle drie varianten en controleert hun volledigheid bij gebruik in when.

Geneste sealed classes

sealed klassen kunnen worden genest, waardoor meerlaagse hiërarchieën ontstaan voor complexe datamodellen zonder verlies van typeveiligheid.

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

Syntaxis van sealed interface (Kotlin 1.5+)

sealed interface wordt op dezelfde manier gedeclareerd als sealed class, maar staat implementatie van meerdere sealed interfaces in één klasse toe.

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

Klasse Navigate implementeert tegelijkertijd twee sealed interfaces — Action en Loggable. Voor sealed class is dit onmogelijk vanwege de beperking van enkelvoudige overerving. sealed interface biedt de flexibiliteit om onafhankelijke hiërarchieën te combineren.

Wanneer sealed interface verkiezen boven sealed class

sealed interface heeft de voorkeur wanneer de hiërarchie geen gedeelde toestand of constructor vereist. Volgens de JetBrains Kotlin Guidelines (2026) moet sealed interface standaard worden gebruikt voor alle nieuwe hiërarchieën waar geen gemeenschappelijke constructor nodig is, waardoor de code flexibeler wordt voor toekomstige uitbreidingen.

Uitputtende verwerking in when

Het belangrijkste voordeel van sealed types is de uitputtende (exhaustive) verwerking in de when-expressie. De compiler controleert of alle mogelijke subklassen zijn meegenomen.

fun handleResult(result: NetworkResult): String = when (result) {
    is NetworkResult.Success -> "Data: ${result.data}"
    is NetworkResult.Error -> "Error: ${result.message}"
    is NetworkResult.Loading -> "Loading..."
    // else is niet vereist — compiler weet dat alle varianten zijn gedekt
}

Als een ontwikkelaar een nieuwe subklasse aan de sealed hiërarchie toevoegt maar vergeet deze in when te verwerken — geeft de compiler een fout. Dit is veiligheid op typeniveau, die niet beschikbaar is bij gebruik van open hiërarchieën met een else-tak.

Volgens Google Android Developers (2026) zijn sealed klassen de aanbevolen manier om UI-toestand in Jetpack Compose te modelleren. De uitputtende when-controle voorkomt situaties waarin de ontwikkelaar niet alle mogelijke weergavevarianten van het scherm heeft verwerkt.

Vergelijking van sealed class met enum class

enum class en sealed class worden vaak verward, maar hebben verschillende doeleinden en mogelijkheden.

Keuze tussen sealed class en enum class hangt af van de taak. Als varianten geen extra gegevens bevatten — gebruik enum. Als elke variant unieke velden bevat — gebruik sealed class of sealed interface.

Praktische toepassingsscenario's

sealed types worden in Kotlin-projecten gebruikt voor een reeks standaard scenario's die typeveilige modellering vereisen.

UI-toestand in Jetpack Compose

Elk Compose-scherm kan een sealed class UiState hebben die alle mogelijke toestanden beschrijft: Idle, Loading, Content(data), Error(exception). De when-expressie garandeert dat alle toestanden zijn verwerkt.

Resultaat van netwerkverzoeken

NetworkResult met varianten Success, Error, Loading — een standaard patroon in Kotlin-projecten met Retrofit en Ktor. sealed class zorgt voor veilige verwerking van elk verzoekresultaat.

Navigatie in multi-module projecten

sealed interface voor navigatieroutes stelt modules in staat hun eigen routes te declareren binnen één hiërarchie. Dit elimineert fouten met onbekende routes tijdens de compilatie.

Volgens KotlinConf (2025) vormen sealed class en sealed interface de basis van type-safe ontwerp in moderne Kotlin-applicaties. Ze worden gecombineerd met data class voor het modelleren van complexe domeinstructuren zonder verlies van veiligheid tijdens de compilatie.