Kotlin Sealed Classes: Enums for Types

Why it exists

Sometimes you need a class hierarchy, but you want to limit it to a specific, known set of types. Open inheritance allows anyone to create new subclasses, which can break logic that assumes a finite number of possibilities. Sealed classes were created to provide controlled inheritance, ensuring all subtypes are known at compile time.

The mental model

Think of a sealed class as an enum, but for class types. An enum defines a fixed set of constant values (like RED, GREEN, BLUE). A sealed class defines a fixed set of subclasses (like Success, Error, Loading). The key difference is that each subclass can be a full-fledged class with its own unique properties and state, whereas enum constants are just single instances.

How it works

You declare a class with the sealed modifier. This makes the class abstract and restricts its direct subclasses to be defined within the same package and module. The real power emerges when you use a sealed class with a when expression. Because the compiler knows every possible subclass, it can perform an exhaustiveness check. If your when statement handles every single subclass, you don't need an else branch. If a developer later adds a new subclass to the hierarchy, any when expressions using it will fail to compile until they are updated to handle the new type.

When to use it

Use sealed classes for modeling a finite set of distinct states or outcomes. This is common in UI development for representing screen state: for example, sealed class UiState with subclasses object Loading, data class Success(val data: List<Item>), and data class Error(val message: String). It's also excellent for defining a library's API errors, ensuring consumers of the library know exactly what kinds of errors they need to handle.

When not to use it

If all your types are simple constants that don't need to carry their own unique data, a simple enum class is more appropriate and lightweight. If you intend for your class hierarchy to be open and extensible by third-party code, use a regular abstract class instead. The point of sealed is restriction, not extension.

One canonical example

A network response can be modeled perfectly with a sealed class. Define sealed class Result<T>. It can have two subclasses: data class Success<T>(val data: T) : Result<T>() and data class Error(val exception: Exception) : Result<Nothing>(). A function that fetches data can return a Result<User>, and the caller can use an exhaustive when to safely handle both the success case (and access the user data) and the error case (and access the exception details).