Sealed Class — wat het is, werkingsprincipe en toepassing

Wat is Sealed Class?

Sealed Class (verzegelde klasse) — dit is een klasse in Kotlin gemarkeerd met de modifier sealed. Het definieert een beperkte typehiërarchie: alle mogelijke overervers worden in hetzelfde bestand opgesomd en de compiler weet van elk van hen. Dit onderscheidt sealed class van een gewone open klasse, waarvan de overervers overal kunnen worden gedeclareerd.

Het hoofddoel van sealed class is type-veilige weergave van een eindige set varianten. Elke overerver kan een eigen gegevensstructuur hebben, wat sealed class flexibeler maakt dan enum. Tijdens runtime is sealed class een gewone abstracte klasse, de compiler legt alleen tijdens compilatie beperkingen op.

Sealed class is vooral nuttig in Android-architectuur van applicaties: UI-toestanden, resultaten van netwerkverzoeken, Intent-achtige navigatiegebeurtenissen en natuurlijk fouthiërarchieën — typische toepassingsscenario's.

Bij compilatie wordt sealed class geoptimaliseerd naar een overgangstabel voor when-expressies, wat het efficiënter maakt dan if-else-ketens. In combinatie met data class kan elke overerver niet alleen toestand, maar ook methoden bevatten, waardoor zelfdocumenterende domeinmodellen zonder boilerplate-code kunnen worden gebouwd.

Sealed class is ook effectief voor het weergeven van eindige automaten (state machine) in mobiele applicaties. Elke toestand — een afzonderlijke overerver met unieke parameters, en overgangen tussen toestanden worden gecontroleerd via de when-expressie. De compiler garandeert dat alle mogelijke toestanden zijn verwerkt, wat runtime-fouten elimineert bij het wijzigen van de UI-toestand of bedrijfslogica.

Sealed Class en Enum: belangrijkste verschillen

Beginnende Kotlin-ontwikkelaars verwarren sealed class vaak met enum, omdat beide de set waarden beperken. Er is echter een fundamenteel verschil: enum — een set constanten van hetzelfde type, sealed class — een hiërarchie van verschillende typen.

Wanneer enum kiezen

Enum is optimaal wanneer alle varianten constanten zijn zonder extra structuur. Bijvoorbeeld dagen van de week, bestelstatussen of actietypen zonder parameters. Elke enum-waarde is een singleton met een vaste naam.

Wanneer sealed class kiezen

Sealed class is nodig wanneer elke variant eigen gegevens heeft. Bijvoorbeeld een netwerkfout bevat een antwoordcode, een parsingfout — details, en een autorisatiefout — een bericht. Elke overerver van sealed class is een afzonderlijk type met unieke velden.

// Enum — alle varianten van één type
enum class Status { LOADING, SUCCESS, ERROR }

// Sealed class — elke variant met eigen gegevens
sealed class UiState<out T> {
    object Loading : UiState<Nothing>()
    data class Success<T>(val data: T) : UiState<T>()
    data class Error(val message: String) : UiState<Nothing>()
}

Sealed Interface versus Sealed Class

Sinds Kotlin 1.5 is het mogelijk om sealed interface te declareren. Dit breidt het sealed-concept uit naar interfaces: sealed interface heeft ook een vaste set implementaties, maar ondersteunt meervoudige overerving.

Wanneer sealed interface gebruiken

Sealed interface is handig wanneer overervers meerdere contracten tegelijk moeten implementeren. Bijvoorbeeld een UI-gebeurtenis kan tegelijkertijd klikbaar en traceerbaar zijn. Met sealed class zou men één basisklasse moeten kiezen, met sealed interface implementeert de overerver beide.

Beperkingen van sealed class

Sealed class is een klasse, dus elke overerver kan slechts één ouder hebben. Sealed interface lost dit probleem op, maar kan geen toestand bevatten. De keuze hangt af van de taak: gemeenschappelijke logica met velden nodig — sealed class, flexibiliteit van contracten nodig — sealed interface.

sealed interface ScreenEvent {
    data class Refresh(val force: Boolean) : ScreenEvent
    data class Navigate(val route: String) : ScreenEvent
    data class ShowError(val toast: String) : ScreenEvent
}

sealed interface AnalyticsEvent {
    val name: String
    val params: Map<String, Any>
}

// Overerver implementeert beide interfaces
data class LoginClicked(
    override val name: String = "login_click",
    override val params: Map<String, Any> = emptyMap()
) : ScreenEvent, AnalyticsEvent

Sealed Class voor fouthiërarchie in mobiele ontwikkeling

Een van de belangrijkste toepassingen van sealed class in mobiele ontwikkeling — type-veilige fouthiërarchie. In plaats van uitzonderingen van verschillende typen te gooien of een algemene Exception te gebruiken, verzamelt sealed class alle mogelijke domeinfouten in één type.

Hoe een fouthiërarchie op te bouwen

Maak een sealed class DomainError en noem alle soorten storingen als overervers. Elke overerver bevat alleen de gegevens die zinvol zijn voor dat fouttype. De compiler garandeert dat u bij het verwerken van de fout geen variant zult vergeten.

Voorbeeld: afhandeling van authenticatiefouten

Beschouw een applicatie met autorisatie, waar verschillende storingsscenario's mogelijk zijn: onjuist wachtwoord, accountblokkering, serverprobleem. Sealed class verenigt ze in één type met uitputtende afhandeling.

sealed class AuthError {
    data class InvalidCredentials(
        val attempts: Int
    ) : AuthError()

    data class AccountBlocked(
        val until: Long
    ) : AuthError()

    data class NetworkFailure(
        val cause: Throwable
    ) : AuthError()

    object ServerError : AuthError()
}

fun handleError(error: AuthError): String = when (error) {
    is AuthError.InvalidCredentials ->
        "Resterende pogingen: ${3 - error.attempts}"
    is AuthError.AccountBlocked ->
        "Toegang geblokkeerd tot ${Date(error.until)}"
    is AuthError.NetworkFailure ->
        "Controleer verbinding: ${error.cause.localizedMessage}"
    AuthError.ServerError ->
        "Server tijdelijk niet beschikbaar"
}

Patronen voor Sealed Class gebruik in Android

Sealed class is een standaardinstrument geworden in de architectuur van Android-applicaties. Laten we drie belangrijke patronen bekijken waarin sealed class onmisbaar is in mobiele ontwikkeling.

• UI State — weergave van het scherm als een eindige automaat: Loading, Content, Error. Elke toestand bevat zijn eigen gegevens, en sealed class garandeert dat alle overgangen zijn verwerkt.
• Navigation Event — sealed class in plaats van navigatieconstanten: elk scherm is een afzonderlijke overerver met routeparameters. De compiler controleert de argumenttypen.
• Action/Intent — het Unidirectional Data Flow patroon gebruikt sealed class om alle acties weer te geven die de gebruiker op het scherm kan uitvoeren.

Afzonderlijk is het vermelden waard de toepassing van sealed class in Clean Architecture. Elke laag (data, domain, presentation) gebruikt sealed class voor zijn fouttypen, en mappers zetten de ene sealed class om in de andere. Bijvoorbeeld DataError uit de gegevenslaag wordt naar DomainError voor bedrijfslogica en vervolgens naar UiState voor de presentatielaag. Dit behoudt type-veiligheid op alle niveaus van de applicatie en garandeert dat geen enkele fout onverwerkt blijft.

Testen van sealed class hiërarchieën

Testen van sealed class vereist een speciale aanpak, omdat elke overerver een afzonderlijk type is met een eigen toestand. Het wordt aanbevolen om geparametriseerde tests te schrijven die alle overervers van sealed class doorlopen. Dit garandeert that when-expressies alle varianten dekken, inclusief nieuwe toegevoegd bij uitbreiding van de hiërarchie.

Voor UI-tests maakt sealed class als UiState het mogelijk om de weergave van elke toestand te controleren: Loading toont een spinner, Content — gegevens, Error — een foutmelding. Omdat sealed class eindig is, geeft testdekking van alle toestanden volledige zekerheid over de juistheid van de UI-logica.

Veelvoorkomende fouten bij het werken met Sealed Class

Ondanks de eenvoud van het concept maken ontwikkelaars regelmatig fouten bij het ontwerpen van sealed class hiërarchieën. Laten we de belangrijkste problemen en manieren om ze te vermijden bekijken.

• Overervers in verschillende bestanden — de compiler staat niet toe sealed class te declareren als overervers zich buiten het bestand bevinden. Deze beperking garandeert uitputtende when.
• Mengen van sealed en open — sealed class kan niet tegelijkertijd open zijn. Als een uitbreidbare hiërarchie nodig is, gebruik dan een gewone abstract class, maar offer exhaustiveness op.
• Overmatige nesting — sealed class in sealed class creëert een diepe hiërarchie die moeilijk te onderhouden is. Voor eenvoudige scenario's zijn twee niveaus voldoende.
• Vergeten else in when — als sealed class uit een bibliotheek geen exhaustiveness heeft, waarschuwt de compiler niet over een gemiste tak. Voeg else alleen bewust toe.