sealed class e interface en Kotlin — qué es, sintaxis y aplicación

¿Qué son sealed class y sealed interface?

sealed class es una clase abstracta con una restricción: todas sus subclases directas deben declararse en el mismo archivo que la propia sealed class. Esta restricción hace que la jerarquía sea cerrada (sealed) — ningún código fuera del archivo puede añadir una nueva subclase.

sealed interface, añadido en Kotlin 1.5, proporciona la misma garantía pero con la flexibilidad de una interfaz: una sealed interface puede ser implementada por múltiples clases, objetos u otras interfaces en un mismo archivo. A diferencia de sealed class, sealed interface no tiene restricción de herencia única — una clase puede implementar varias interfaces sealed a la vez.

Según Kotlin Evolution and Roadmap (2026), sealed interface se añadió por petición de la comunidad para un modelado más flexible. La motivación principal es la capacidad de combinar jerarquías de tipos independientes sin herencia múltiple de clases.

Sintaxis de sealed class

La declaración de una sealed class comienza con el modificador sealed antes de class. Las subclases se declaran en el mismo archivo.

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

Cada subclase de una sealed class puede tener sus propias propiedades y métodos. Loading es un singleton (object), Success y Error son data classes con parámetros. El compilador conoce las tres variantes y verifica su integridad cuando se usan en when.

Sealed classes anidadas

Las clases sealed pueden anidarse, creando jerarquías de múltiples niveles para modelos de datos complejos sin 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()
}

Sintaxis de sealed interface (Kotlin 1.5+)

sealed interface se declara de forma similar a sealed class, pero permite implementar varias interfaces sealed en una sola clase.

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

La clase Navigate implementa dos interfaces sealed a la vez — Action y Loggable. Esto es imposible con sealed class debido a la restricción de herencia única. sealed interface proporciona la flexibilidad de combinar jerarquías independientes.

Cuándo elegir sealed interface en lugar de sealed class

sealed interface es preferible cuando la jerarquía no requiere estado compartido ni constructor. Según las JetBrains Kotlin Guidelines (2026), sealed interface debe usarse por defecto para todas las jerarquías nuevas donde no se necesite un constructor común, lo que hace el código más flexible para futuras extensiones.

Manejo exhaustivo en when

La principal ventaja de los tipos sealed es el manejo exhaustivo en la expresión when. El compilador verifica que todas las subclases posibles estén cubiertas.

fun handleResult(result: NetworkResult): String = when (result) {
    is NetworkResult.Success -> "Data: ${result.data}"
    is NetworkResult.Error -> "Error: ${result.message}"
    is NetworkResult.Loading -> "Loading..."
    // else no es necesario — el compilador sabe que todas las variantes están cubiertas
}

Si un desarrollador añade una nueva subclase a una jerarquía sealed pero olvida manejarla en when — el compilador lanzará un error. Esto es seguridad a nivel de tipos, no disponible con jerarquías abiertas que usan rama else.

Según Google Android Developers (2026), las clases sealed son la forma recomendada de modelar el estado de UI en Jetpack Compose. La verificación exhaustiva de when previene estados en los que el desarrollador no ha manejado todas las variantes posibles de visualización de una pantalla.

Comparación sealed class con enum class

enum class y sealed class a menudo se confunden, pero tienen diferentes propósitos y capacidades.

La elección entre sealed class y enum class depende de la tarea. Si las variantes no llevan datos adicionales — use enum. Si cada variante contiene campos únicos — use sealed class o sealed interface.

Escenarios prácticos de uso

Los tipos sealed se usan en proyectos Kotlin para una serie de escenarios estándar donde se requiere modelado type-safe.

Estado de UI en Jetpack Compose

Cada pantalla de Compose puede tener una sealed class UiState que describa todos los estados posibles: Idle, Loading, Content(data), Error(exception). La expresión when garantiza que todos los estados sean manejados.

Resultados de solicitudes de red

NetworkResult con las variantes Success, Error, Loading es un patrón estándar en proyectos Kotlin con Retrofit y Ktor. sealed class proporciona un manejo seguro de cada resultado de la solicitud.

Navegación en proyectos multi-módulo

sealed interface para rutas de navegación permite que los módulos declaren sus propias rutas manteniéndose dentro de una jerarquía unificada. Esto elimina errores con rutas desconocidas en tiempo de compilación.

Según KotlinConf (2025), sealed class y sealed interface son la base del diseño type-safe en aplicaciones Kotlin modernas. Se combinan con data class para modelar estructuras de dominio complejas sin perder seguridad en tiempo de compilación.