Wat is een "sealed class" in Kotlin en hoe vergemakkelijkt het de afhandeling van toestanden? Hoe zijn sealed classes gerelateerd aan het when-expressie en waarom is dit belangrijk voor type-safety? Geef een voorbeeld van gebruik.

Antwoord

sealed class in Kotlin is een abstracte klasse die de hiërarchie van afgeleiden beperkt: alle subtypes moeten in hetzelfde bestand worden gedeclareerd. Dit is handig voor hiërarchieën waarin de set opties vast is (bijvoorbeeld voor het beschrijven van toestanden, gebeurtenissen of fouten):

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("Success!")
    is Result.Error -> println("Error: ${result.message}")
    is Result.Loading -> println("Loading...")
}

Relatie met when: Als we alle subtypen van de sealed class gebruiken in een when-expressie, controleert de compiler op exhaustiveness (uitputtende afhandeling van opties). Dit garandeert dat wanneer een nieuwe toestand wordt toegevoegd, de ontwikkelaar een compileerfout krijgt als er geen rekening wordt gehouden met de nieuwe optie.

Waarom is dit belangrijk:

• Vereenvoudigt de ondersteuning van type-safety.
• Onafhankelijkheid van runtime-controles; de afhandeling vindt plaats tijdens de compilatie.
• Dwingt je om expliciet rekening te houden met alle opties in de hiërarchie.

---

Vraag met een haakje

"Kunnen de afgeleiden van een sealed class in verschillende bestanden of pakketten worden geplaatst? Hoe beïnvloedt dit de type-safety?"

Antwoord: Nee, alle directe afgeleiden van een sealed class moeten in hetzelfde bestand worden gedefinieerd. Dit is een controle van de compiler voor garanties van type-safety. Als de afgeleiden in andere bestanden van het pakket worden geplaatst, geeft de compiler een foutmelding.

---

Voorbeelden van echte fouten door gebrek aan kennis van de fijne kneepjes van het onderwerp

---

Verhaal

Bij het ontwerpen van de business-logica voor betalingen hebben we resultaten van operaties toegevoegd, maar vergeten het when-expressie bij te werken. Maar dankzij de sealed class heeft de compiler de niet-verwerkte gevallen gemarkeerd. In een ander project in Java zou dit scenario hebben geleid tot het invoeren van een niet-geïnitialiseerde status in het product.

---

Verhaal

In een project, na de migratie van een deel van de gegevens van sealed classes naar gewone open classes, werkten de uitputtende when-controles niet meer — nieuwe statussen begonnen "verdwenen" te raken in de verwerkingslogica, wat leidde tot incorrect gedrag van de interface.

---

Verhaal

In een e-commerce systeem was er een poging om de architectuur te optimaliseren door de afgeleiden van sealed classes naar aparte bestanden te verplaatsen (elk in zijn eigen module voor hergebruik). Dit brak de compilatie en veroorzaakte een noodrefactoring voor de release.