sealed class and interface in Kotlin — what it is, syntax and usage

What is a sealed class and sealed interface?

sealed class is an abstract class with a restriction: all its direct subclasses must be declared in the same file as the sealed class itself. This restriction makes the hierarchy closed (sealed) — no code outside the file can add a new subclass.

sealed interface, added in Kotlin 1.5, provides the same guarantee but with the flexibility of an interface: a sealed interface can be implemented by multiple classes, objects, or other interfaces in one file. Unlike a sealed class, a sealed interface has no single inheritance restriction — a class can implement multiple sealed interfaces at once.

According to the Kotlin Evolution and Roadmap (2026), sealed interface was added by community request for more flexible modeling. The main motivation is the ability to combine independent type hierarchies without multiple class inheritance.

Sealed class syntax

Declaring a sealed class starts with the sealed modifier before class. Subclasses are declared in the same file.

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

Each subclass of a sealed class can have its own properties and methods. Loading is a singleton (object), Success and Error are data classes with parameters. The compiler knows all three variants and checks their completeness when used in when.

Nested sealed classes

sealed classes can be nested, creating multi-level hierarchies for complex data models without losing 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 syntax (Kotlin 1.5+)

sealed interface is declared similarly to a sealed class but allows implementing multiple sealed interfaces in one class.

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

The Navigate class implements two sealed interfaces at once — Action and Loggable. This is impossible with a sealed class due to single inheritance restriction. Sealed interface provides the flexibility to combine independent hierarchies.

When to choose sealed interface over sealed class

sealed interface is preferable when the hierarchy does not require shared state or a constructor. According to the JetBrains Kotlin Guidelines (2026), sealed interface should be used by default for all new hierarchies where a common constructor is not needed, making the code more flexible for future extensions.

Exhaustive handling in when

The main advantage of sealed types is exhaustive handling in when-expressions. The compiler checks that all possible subclasses are covered.

fun handleResult(result: NetworkResult): String = when (result) {
    is NetworkResult.Success -> "Data: ${result.data}"
    is NetworkResult.Error -> "Error: ${result.message}"
    is NetworkResult.Loading -> "Loading..."
    // else is not required — compiler knows all variants are covered
}

If a developer adds a new subclass to a sealed hierarchy but forgets to handle it in when — the compiler will raise an error. This is safety at the type level, unavailable with open hierarchies using else branches.

According to Google Android Developers (2026), sealed classes are the recommended way to model UI state in Jetpack Compose. Exhaustive when checking prevents states where a developer has not handled all possible display variants of a screen.

Sealed class vs enum class comparison

enum class and sealed class are often confused, but they have different purposes and capabilities.

Choosing between sealed class and enum class depends on the task. If variants carry no additional data — use enum. If each variant contains unique fields — use sealed class or sealed interface.

Practical use cases

sealed types are used in Kotlin projects for a range of standard scenarios where type-safe modeling is required.

UI state in Jetpack Compose

Each Compose screen can have a sealed class UiState describing all possible states: Idle, Loading, Content(data), Error(exception). A when expression guarantees all states are handled.

Network request results

NetworkResult with variants Success, Error, Loading is a standard pattern in Kotlin projects with Retrofit and Ktor. Sealed class ensures safe handling of each request outcome.

Navigation in multi-module projects

sealed interface for navigation routes allows modules to declare their own routes while staying within a unified hierarchy. This eliminates errors with unknown routes at compile time.

According to KotlinConf (2025), sealed class and sealed interface are the foundation of type-safe design in modern Kotlin applications. They combine with data class to model complex domain structures without losing safety at compile time.