sealed class та interface у Kotlin — що це, синтаксис і застосування

Що таке sealed class і sealed interface?

sealed class — це абстрактний клас з обмеженням: всі його прямі підкласи мають бути оголошені в тому ж файлі, що й сам sealed class. Це обмеження робить ієрархію закритою (sealed) — жоден код за межами файлу не може додати новий підклас.

sealed interface, доданий у Kotlin 1.5, надає ту ж гарантію, але з гнучкістю інтерфейсу: sealed interface може бути реалізований кількома класами, об'єктами або іншими інтерфейсами в одному файлі. На відміну від sealed class, sealed interface не має обмеження на одинарне спадкування — клас може реалізувати кілька sealed інтерфейсів одночасно.

За даними Kotlin Evolution and Roadmap (2026), sealed interface був доданий на запит спільноти для більш гнучкого моделювання. Основна мотивація — можливість комбінувати незалежні ієрархії типів без множинного спадкування класів.

Синтаксис sealed class

Оголошення sealed class починається з модифікатора sealed перед class. Підкласи оголошуються в тому ж файлі.

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

Кожен підклас sealed class може мати власні властивості та методи. Loading — це singleton (object), Success і Error — data class з параметрами. Компілятор знає всі три варіанти та перевіряє їх повноту при використанні в when.

Вкладені sealed class

Sealed класи можуть бути вкладеними, створюючи багаторівневі ієрархії для складних моделей даних без втрати type safety.

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

Синтаксис sealed interface (Kotlin 1.5+)

sealed interface оголошується аналогічно sealed class, але дозволяє реалізовувати кілька sealed інтерфейсів в одному класі.

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

Клас Navigate реалізує одразу два sealed інтерфейси — Action і Loggable. Для sealed class це неможливо через обмеження одинарного спадкування. sealed interface дає гнучкість комбінування незалежних ієрархій.

Коли вибирати sealed interface замість sealed class

sealed interface переважніший, коли ієрархія не вимагає спільного стану або конструктора. Згідно з JetBrains Kotlin Guidelines (2026), sealed interface слід використовувати за замовчуванням для всіх нових ієрархій, де не потрібен спільний конструктор, що робить код більш гнучким для майбутніх розширень.

Вичерпна обробка в when

Головна перевага sealed типів — вичерпна (exhaustive) обробка в when-виразі. Компілятор перевіряє, що всі можливі підкласи враховані.

fun handleResult(result: NetworkResult): String = when (result) {
    is NetworkResult.Success -> "Data: ${result.data}"
    is NetworkResult.Error -> "Error: ${result.message}"
    is NetworkResult.Loading -> "Loading..."
    // else не потрібен — компілятор знає, що всі варіанти покриті
}

Якщо розробник додасть новий підклас у sealed ієрархію, але забуде обробити його в when — компілятор видасть помилку. Це безпека на рівні типів, недоступна при використанні відкритих ієрархій з else-гілкою.

За даними Google Android Developers (2026), sealed класи — рекомендований спосіб моделювання UI-стану в Jetpack Compose. Вичерпна перевірка when запобігає станам, коли розробник обробив не всі можливі варіанти відображення екрана.

Порівняння sealed class з enum class

enum class і sealed class часто плутають, але у них різні призначення та можливості.

Вибір між sealed class і enum class залежить від завдання. Якщо варіанти не несуть додаткових даних — використовуйте enum. Якщо кожен варіант містить унікальні поля — використовуйте sealed class або sealed interface.

Практичні сценарії застосування

Sealed типи використовуються в Kotlin-проєктах для низки стандартних сценаріїв, де потрібне type-safe моделювання.

UI-стан у Jetpack Compose

Кожен екран Compose може мати sealed class UiState, який описує всі можливі стани: Idle, Loading, Content(data), Error(exception). when вираз гарантує, що всі стани оброблені.

Результат мережевих запитів

NetworkResult з варіантами Success, Error, Loading — стандартний патерн у Kotlin-проєктах з Retrofit і Ktor. sealed class забезпечує безпечну обробку кожного результату запиту.

Навігація в multi-module проєктах

sealed interface для маршрутів навігації дозволяє модулям оголошувати свої маршрути, залишаючись у межах єдиної ієрархії. Це виключає помилки з невідомими маршрутами на етапі компіляції.

За даними KotlinConf (2025), sealed class і sealed interface — основа type-safe дизайну в сучасних Kotlin-застосунках. Вони комбінуються з data class для моделювання складних доменних структур без втрати безпеки на етапі компіляції.