skip to content

When would you choose a sealed interface over a sealed class, and what capabilities differ between them?

level: middleimportance: should knowfreq 55%

answer

  1. Class: single inheritance + state + constructor
  2. Interface: multiple inheritance, no backing fields
  3. Interface lets a type join several closed sets
  4. Both: closed subtype set, same module + package
  5. Sealed class is implicitly abstract

basics

~20 s

Use a sealed interface when a type may need to belong to several closed hierarchies at once, since a class can implement many interfaces but extend only one class. Use a sealed class when you want shared state (stored properties) or a single constructor in the parent.

solid answer

~40 s

Both give a closed set of subtypes, but they differ like normal classes vs interfaces. A `sealed class` is a single-inheritance parent: it can declare constructors and backing fields (stored state) shared by all subtypes, but a subtype can extend only one class. A `sealed interface` has no constructor and no backing fields, but supports **multiple inheritance** — a subtype can implement several sealed interfaces, letting one type participate in more than one closed hierarchy (useful for intersecting categorizations or marker-style grouping). Sealed interfaces also compose better with existing public interfaces. Choose a sealed class when subtypes share concrete state or initialization; choose a sealed interface when you need flexible, multiple membership or want to seal an interface that types already implement.

code

kotlin · 6 lines
kotlin
sealed interface Error
sealed interface Retryable

// participates in two closed hierarchies at once
data class Timeout(val ms: Long) : Error, Retryable
data class NotFound(val id: String) : Error // Error only

go deeper

for a junior

Knows both exist and that an interface can be implemented multiple times.

for a middle

Cites the concrete differences (state/constructor vs multiple inheritance) and picks correctly for a scenario.

for a senior

Weighs API evolution and composability — e.g. sealing an existing interface vs forcing single inheritance.

for a principal

Designs hierarchies where intersecting sealed interfaces express orthogonal invariants, considering binary compatibility of each choice.

## Same guarantee, different shape Both `sealed class` and `sealed interface` give you a **closed set of subtypes** known at compile time. The choice mirrors the ordinary class-vs-interface trade-offs. ## Sealed class - **Single inheritance:** a subtype can extend only one class total, so being a subtype of a sealed *class* uses up that single slot. - **Can have a constructor and stored state:** the parent can declare `val`/`var` properties with backing fields and an `init` block, shared by all subtypes. - **Implicitly abstract**, so it cannot be instantiated. ```kotlin sealed class Animal(val legs: Int) { // shared stored state class Dog : Animal(4) class Bird : Animal(2) } ``` ## Sealed interface - **Multiple inheritance:** a type can implement many interfaces, so it can belong to several sealed hierarchies at once. - **No constructor, no backing fields:** only abstract members and default-method bodies (properties without backing fields). - Lets you make an *existing* interface closed without forcing everything into one inheritance line. ```kotlin sealed interface Serializable2 sealed interface Comparable2 // one type can be in BOTH closed sets data class Money(val cents: Long) : Serializable2, Comparable2 ``` ## Decision guide - Need **shared concrete state / a constructor** → sealed **class**. - Need a subtype to be in **multiple** closed hierarchies, or to combine with other interfaces → sealed **interface**. - Want to retrofit closedness onto an interface types already implement → sealed **interface**. ## Note on subtype kinds A subtype of either can itself be a `data class`, `object`, regular `class`, or another `sealed` type. The closed-set rule (same module, same package) is identical for both.

  • Can a single class be a subtype of two different sealed classes?
    No. A class can extend only one class, so it can be a direct subtype of at most one sealed class — but it can implement multiple sealed interfaces.
  • Can a sealed interface hold stored state?
    No backing fields. It can declare abstract properties and provide default getters, but cannot store state like a class constructor parameter does.

A sealed class is a family bloodline (you have exactly one), a sealed interface is a club membership (you can join several).

saying these in an interview costs you the question

  • Saying sealed interfaces can have constructors or backing fields
  • Claiming there's no difference at all between the two
  • Thinking a class can extend multiple sealed classes
  • Recommending sealed class purely out of habit when multiple membership is needed

context

resolving links…