sealed class i interface w Kotlin — co to jest, składnia i zastosowanie

Czym są sealed class i sealed interface?

sealed class to klasa abstrakcyjna z ograniczeniem: wszystkie jej bezpośrednie podklasy muszą być zadeklarowane w tym samym pliku co sealed class. To ograniczenie sprawia, że hierarchia jest zamknięta (sealed) — żaden kod poza plikiem nie może dodać nowej podklasy.

sealed interface, dodany w Kotlin 1.5, zapewnia tę samą gwarancję, ale z elastycznością interfejsu: sealed interface może być zaimplementowany przez wiele klas, obiektów lub innych interfejsów w jednym pliku. W przeciwieństwie do sealed class, sealed interface nie ma ograniczenia pojedynczego dziedziczenia — klasa może implementować wiele sealed interfejsów jednocześnie.

Według Kotlin Evolution and Roadmap (2026), sealed interface został dodany na prośbę społeczności w celu bardziej elastycznego modelowania. Główną motywacją była możliwość łączenia niezależnych hierarchii typów bez wielodziedziczenia klas.

Składnia sealed class

Deklaracja sealed class zaczyna się od modyfikatora sealed przed class. Podklasy są deklarowane w tym samym pliku.

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

Każda podklasa sealed class może mieć własne właściwości i metody. Loading to singleton (object), Success i Error to data class z parametrami. Kompilator zna wszystkie trzy warianty i sprawdza ich kompletność przy użyciu w when.

Zagnieżdżone sealed class

sealed klasy mogą być zagnieżdżone, tworząc wielopoziomowe hierarchie dla złożonych modeli danych bez utraty bezpieczeństwa typów.

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

Składnia sealed interface (Kotlin 1.5+)

sealed interface jest deklarowany podobnie do sealed class, ale pozwala na implementację wielu sealed interfejsów w jednej klasie.

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

Klasa Navigate implementuje jednocześnie dwa sealed interfejsy — Action i Loggable. Dla sealed class jest to niemożliwe ze względu na ograniczenie pojedynczego dziedziczenia. sealed interface daje elastyczność łączenia niezależnych hierarchii.

Kiedy wybrać sealed interface zamiast sealed class

sealed interface jest preferowany, gdy hierarchia nie wymaga wspólnego stanu ani konstruktora. Zgodnie z JetBrains Kotlin Guidelines (2026), sealed interface powinien być używany domyślnie dla wszystkich nowych hierarchii, gdzie nie jest potrzebny wspólny konstruktor, co czyni kod bardziej elastycznym na przyszłe rozszerzenia.

Wyczerpująca obsługa w when

Główną zaletą typów sealed jest wyczerpująca (exhaustive) obsługa w wyrażeniu when. Kompilator sprawdza, czy wszystkie możliwe podklasy zostały uwzględnione.

fun handleResult(result: NetworkResult): String = when (result) {
    is NetworkResult.Success -> "Data: ${result.data}"
    is NetworkResult.Error -> "Error: ${result.message}"
    is NetworkResult.Loading -> "Loading..."
    // else nie jest wymagane — kompilator wie, że wszystkie warianty są obsłużone
}

Jeśli programista doda nową podklasę w sealed hierarchii, ale zapomni obsłużyć ją w when — kompilator zgłosi błąd. To bezpieczeństwo na poziomie typów, niedostępne przy użyciu otwartych hierarchii z gałęzią else.

Według Google Android Developers (2026), sealed klasy to zalecany sposób modelowania stanu UI w Jetpack Compose. Wyczerpująca kontrola when zapobiega sytuacjom, w których programista obsłużył nie wszystkie możliwe warianty wyświetlania ekranu.

Porównanie sealed class z enum class

enum class i sealed class są często mylone, ale mają różne przeznaczenie i możliwości.

Wybór między sealed class a enum class zależy od zadania. Jeśli warianty nie niosą dodatkowych danych — użyj enum. Jeśli każdy wariant zawiera unikalne pola — użyj sealed class lub sealed interface.

Praktyczne scenariusze zastosowania

sealed typy są używane w projektach Kotlin do wielu standardowych scenariuszy wymagających modelowania z bezpieczeństwem typów.

Stan UI w Jetpack Compose

Każdy ekran Compose może mieć sealed class UiState, która opisuje wszystkie możliwe stany: Idle, Loading, Content(data), Error(exception). Wyrażenie when gwarantuje, że wszystkie stany są obsłużone.

Wynik zapytań sieciowych

NetworkResult z wariantami Success, Error, Loading to standardowy wzorzec w projektach Kotlin z Retrofit i Ktor. sealed class zapewnia bezpieczną obsługę każdego wyniku zapytania.

Nawigacja w projektach multi-module

sealed interface dla tras nawigacji pozwala modułom deklarować własne trasy, pozostając w ramach jednej hierarchii. Eliminuje to błędy z nieznanymi trasami na etapie kompilacji.

Według KotlinConf (2025), sealed class i sealed interface stanowią podstawę type-safe projektowania w nowoczesnych aplikacjach Kotlin. Łączy się je z data class do modelowania złożonych struktur domenowych bez utraty bezpieczeństwa na etapie kompilacji.