sealed class och interface i Kotlin — vad är det, syntax och tillämpning

Vad är sealed class och sealed interface?

sealed class är en abstrakt klass med en begränsning: alla dess direkta underklasser måste deklareras i samma fil som sealed-klassen. Denna begränsning gör hierarkin sluten (sealed) — ingen kod utanför filen kan lägga till en ny underklass.

sealed interface, tillagt i Kotlin 1.5, ger samma garanti men med gränssnittets flexibilitet: sealed interface kan implementeras av flera klasser, objekt eller andra gränssnitt i en fil. Till skillnad från sealed class har sealed interface ingen begränsning för enkelarv — en klass kan implementera flera sealed-gränssnitt samtidigt.

Enligt Kotlin Evolution and Roadmap (2026) lades sealed interface till på begäran av communityn för mer flexibel modellering. Huvudmotivationen var möjligheten att kombinera oberoende typer av hierarkier utan multipel klassarv.

Syntax för sealed class

Deklaration av sealed class börjar med modifieraren sealed före class. Underklasser deklareras i samma fil.

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

Varje underklass till sealed class kan ha egna egenskaper och metoder. Loading är en singleton (object), Success och Error är data class med parametrar. Kompilatorn känner till alla tre varianter och kontrollerar deras fullständighet vid användning i when.

Nästlade sealed classes

sealed klasser kan vara nästlade och skapa flernivåhierarkier för komplexa datamodeller utan förlust av typsäkerhet.

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 för sealed interface (Kotlin 1.5+)

sealed interface deklareras på liknande sätt som sealed class, men tillåter implementering av flera sealed-gränssnitt i en klass.

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

Klassen Navigate implementerar samtidigt två sealed-gränssnitt — Action och Loggable. För sealed class är detta omöjligt på grund av begränsningen för enkelarv. sealed interface ger flexibilitet att kombinera oberoende hierarkier.

När ska man välja sealed interface framför sealed class

sealed interface är att föredra när hierarkin inte kräver delat tillstånd eller konstruktor. Enligt JetBrains Kotlin Guidelines (2026) bör sealed interface användas som standard för alla nya hierarkier där ingen gemensam konstruktor behövs, vilket gör koden mer flexibel för framtida utökningar.

Uttömmande bearbetning i when

Den främsta fördelen med sealed-typer är uttömmande (exhaustive) bearbetning i when-uttrycket. Kompilatorn kontrollerar att alla möjliga underklasser har beaktats.

fun handleResult(result: NetworkResult): String = when (result) {
    is NetworkResult.Success -> "Data: ${result.data}"
    is NetworkResult.Error -> "Error: ${result.message}"
    is NetworkResult.Loading -> "Loading..."
    // else krävs inte — kompilatorn vet att alla varianter täcks
}

Om en utvecklare lägger till en ny underklass i sealed-hierarkin men glömmer att bearbeta den i when — kommer kompilatorn att ge ett fel. Detta är säkerhet på typnivå, som inte är tillgänglig vid användning av öppna hierarkier med else-gren.

Enligt Google Android Developers (2026) är sealed-klasser det rekommenderade sättet att modellera UI-tillstånd i Jetpack Compose. Uttömmande when-kontroll förhindrar situationer där utvecklaren inte har bearbetat alla möjliga varianter av skärmvisning.

Jämförelse av sealed class med enum class

enum class och sealed class blandas ofta ihop, men de har olika syften och möjligheter.

Val mellan sealed class och enum class beror på uppgiften. Om varianter inte bär ytterligare data — använd enum. Om varje variant innehåller unika fält — använd sealed class eller sealed interface.

Praktiska tillämpningsscenarier

Sealed-typer används i Kotlin-projekt för en rad standardscenarier som kräver typsäker modellering.

UI-tillstånd i Jetpack Compose

Varje Compose-skärm kan ha en sealed class UiState som beskriver alla möjliga tillstånd: Idle, Loading, Content(data), Error(exception). When-uttrycket garanterar att alla tillstånd har bearbetats.

Resultat av nätverksförfrågningar

NetworkResult med varianterna Success, Error, Loading — ett standardmönster i Kotlin-projekt med Retrofit och Ktor. sealed class säkerställer säker bearbetning av varje förfrågningsresultat.

Navigering i multi-modulprojekt

sealed interface för navigeringsvägar tillåter moduler att deklarera sina egna vägar inom en enhetlig hierarki. Detta eliminerar fel med okända vägar vid kompilering.

Enligt KotlinConf (2025) utgör sealed class och sealed interface grunden för type-safe design i moderna Kotlin-applikationer. De kombineras med data class för att modellera komplexa domänstrukturer utan förlust av säkerhet vid kompilering.