sealed class e interface em Kotlin — o que é, sintaxe e aplicação

O que são sealed class e sealed interface?

sealed class é uma classe abstrata com uma restrição: todas as suas subclasses diretas devem ser declaradas no mesmo arquivo que a própria sealed class. Essa restrição torna a hierarquia fechada (sealed) — nenhum código fora do arquivo pode adicionar uma nova subclasse.

sealed interface, adicionada no Kotlin 1.5, fornece a mesma garantia mas com a flexibilidade de uma interface: uma sealed interface pode ser implementada por múltiplas classes, objetos ou outras interfaces em um arquivo. Ao contrário de sealed class, sealed interface não tem restrição de herança única — uma classe pode implementar várias interfaces sealed ao mesmo tempo.

De acordo com Kotlin Evolution and Roadmap (2026), sealed interface foi adicionada por solicitação da comunidade para modelagem mais flexível. A principal motivação é a capacidade de combinar hierarquias de tipos independentes sem herança múltipla de classes.

Sintaxe de sealed class

A declaração de uma sealed class começa com o modificador sealed antes de class. As subclasses são declaradas no mesmo arquivo.

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

Cada subclasse de uma sealed class pode ter suas próprias propriedades e métodos. Loading é um singleton (object), Success e Error são data classes com parâmetros. O compilador conhece todas as três variantes e verifica sua completeza quando usadas em when.

Sealed classes aninhadas

As classes sealed podem ser aninhadas, criando hierarquias de vários níveis para modelos de dados complexos sem perder 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()
}

Sintaxe de sealed interface (Kotlin 1.5+)

sealed interface é declarada de forma semelhante a sealed class, mas permite implementar várias interfaces sealed em uma única classe.

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

A classe Navigate implementa duas interfaces sealed ao mesmo tempo — Action e Loggable. Isso é impossível com sealed class devido à restrição de herança única. sealed interface oferece a flexibilidade de combinar hierarquias independentes.

Quando escolher sealed interface em vez de sealed class

sealed interface é preferível quando a hierarquia não requer estado compartilhado ou construtor. De acordo com as JetBrains Kotlin Guidelines (2026), sealed interface deve ser usada por padrão para todas as hierarquias novas onde um construtor comum não é necessário, tornando o código mais flexível para extensões futuras.

Tratamento exaustivo em when

A principal vantagem dos tipos sealed é o tratamento exaustivo na expressão when. O compilador verifica que todas as subclasses possíveis estão cobertas.

fun handleResult(result: NetworkResult): String = when (result) {
    is NetworkResult.Success -> "Data: ${result.data}"
    is NetworkResult.Error -> "Error: ${result.message}"
    is NetworkResult.Loading -> "Loading..."
    // else não é necessário — o compilador sabe que todas as variantes estão cobertas
}

Se um desenvolvedor adicionar uma nova subclasse a uma hierarquia sealed mas esquecer de tratá-la no when — o compilador lançará um erro. Isso é segurança no nível de tipos, indisponível com hierarquias abertas que usam ramo else.

De acordo com Google Android Developers (2026), as classes sealed são a forma recomendada de modelar estado de UI no Jetpack Compose. A verificação exaustiva de when previne estados onde o desenvolvedor não tratou todas as variantes possíveis de exibição de uma tela.

Comparação sealed class com enum class

enum class e sealed class são frequentemente confundidas, mas têm propósitos e capacidades diferentes.

A escolha entre sealed class e enum class depende da tarefa. Se as variantes não carregam dados adicionais — use enum. Se cada variante contém campos únicos — use sealed class ou sealed interface.

Cenários práticos de uso

Os tipos sealed são usados em projetos Kotlin para uma série de cenários padrão onde a modelagem type-safe é necessária.

Estado de UI no Jetpack Compose

Cada tela Compose pode ter uma sealed class UiState descrevendo todos os estados possíveis: Idle, Loading, Content(data), Error(exception). A expressão when garante que todos os estados sejam tratados.

Resultados de requisições de rede

NetworkResult com as variantes Success, Error, Loading é um padrão comum em projetos Kotlin com Retrofit e Ktor. sealed class garante o tratamento seguro de cada resultado de requisição.

Navegação em projetos multi-módulo

sealed interface para rotas de navegação permite que módulos declarem suas próprias rotas enquanto permanecem dentro de uma hierarquia unificada. Isso elimina erros com rotas desconhecidas em tempo de compilação.

De acordo com KotlinConf (2025), sealed class e sealed interface são a base do design type-safe em aplicações Kotlin modernas. Elas se combinam com data class para modelar estruturas de domínio complexas sem perder segurança em tempo de compilação.