Respuesta.

Historia de la pregunta:

Las interfaces con el modificador sealed aparecieron en Kotlin como una evolución del concepto de sealed class. Hasta Kotlin 1.5, solo las clases sealed permitían limitar el conjunto de posibles herederos, lo cual es especialmente importante para trabajar de manera segura con jerarquías de estados (máquinas de estados, DSL, etc.). Al introducir las interfaces sealed, los desarrolladores proporcionaron la posibilidad de limitar las implementaciones de interfaces de manera similar, sin estar atados a clases.

Problema:

Una interfaz abierta simple puede ser implementada en cualquier parte del programa, lo que puede llevar a un crecimiento incontrolado en el número de implementaciones y complicar el mantenimiento del código. Al manejar a través de una expresión when, el compilador no puede advertir sobre ramas no consideradas.

Solución:

La sealed interface limita las implementaciones solo a las que se definen en un mismo módulo (o en el mismo archivo, si la interfaz no es de nivel superior). Este tipo de control se aplica a estructuras similares a enums seguras, patrones ADT y manejadores de estado. El compilador conoce todas las implementaciones y ayuda durante el análisis del código.

Ejemplo de código:

sealed interface NetworkResult

class Success(val data: String): NetworkResult
class Error(val cause: Throwable): NetworkResult
object Loading: NetworkResult

fun handleResult(result: NetworkResult): String = when (result) {
    is Success -> "Success con ${result.data}"
    is Error -> "Error: ${result.cause.message}"
    Loading -> "Cargando..."
}

Características clave:

Las interfaces sealed proporcionan una limitación en la cantidad de implementaciones para mejorar la seguridad de tipos.
Funcionan con la expresión when: el compilador verifica la exhaustividad.
Las implementaciones pueden ser tanto clases como objetos y otros tipos sealed, pero solo dentro de un mismo módulo.

Preguntas capciosas.

¿Es posible implementar una sealed interface fuera del archivo actual?

Respuesta: A diferencia de las sealed class, las interfaces sealed pueden ser implementadas en otros archivos, pero solo dentro del módulo actual (o unidad de compilación, si la interfaz no es de nivel superior).

¿Pueden las sealed interfaces tener métodos abiertos con implementaciones por defecto?

Sí, al igual que las interfaces normales, una interfaz sealed puede contener implementaciones por defecto de funciones.

sealed interface Mode {
    fun description(): String = "Modo desconocido"
}

¿Es posible serializar una sealed interface utilizando serializadores estándar (por ejemplo, kotlinx.serialization)?

Es posible, pero será necesario indicar explícitamente todas las implementaciones. En kotlinx.serialization, el soporte para interfaces sealed no llegó de inmediato, es importante especificar claramente los tipos serializables.

Errores típicos y anti-patrones

Definición de implementaciones fuera del módulo
Uso excesivo de interfaces sealed en lugar de enums, cuando hay menos opciones y la estructura es más simple
No realizar una verificación de exhaustividad al actualizar la sealed interface

Ejemplo de la vida real

Caso negativo

En el proyecto se describió una sealed interface para todos los tipos de estados de UI, y las implementaciones comenzaron a aparecer en diferentes partes de la aplicación. Luego se añadió un nuevo tipo de estado y se olvidó actualizar el bloque de manejo, lo que llevó a ignorar el nuevo estado en los registros.

Ventajas:

Rápida adición de nuevos estados

Desventajas:

Se pierde la seguridad de tipos, aparecen ramas no consideradas en la lógica

Caso positivo

Se utilizó una sealed interface para todas las respuestas de red. Gracias a ello, al añadir un nuevo tipo de respuesta, la IDE iluminó inmediatamente todos los lugares donde se maneja a través de when. El error se corrige de inmediato, no hay huecos inesperados en la lógica.