¿Qué es una "sealed class" en Kotlin y cómo simplifican el manejo de estados? ¿Cómo se relacionan las sealed classes con la expresión when y por qué es importante para la type-safety? Proporcione un ejemplo de uso.

Respuesta

sealed class en Kotlin es una clase abstracta que limita la jerarquía de herederos: todos los subtipos deben ser declarados en un solo archivo. Esto es útil para jerarquías donde el conjunto de variantes es fijo (por ejemplo, para describir estados, eventos o errores):

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

fun handle(result: Result) = when (result) {
    is Result.Success -> print("¡Éxito!")
    is Result.Error -> println("Error: ${result.message}")
    is Result.Loading -> println("Cargando...")
}

Relación con when: Si utilizamos todos los subtipos de la sealed class en la expresión when, el compilador verifica la exhaustividad (análisis exhaustivo de variantes). Esto garantiza que al añadir un nuevo estado, el desarrollador recibirá un error de compilación si no maneja la nueva variante.

Por qué es necesario:

• Simplifica el mantenimiento de la type-safety.
• Independencia de las verificaciones en tiempo de ejecución, el manejo ocurre en la etapa de compilación.
• Obliga a considerar explícitamente todas las variantes de la jerarquía.

---

Pregunta trampa

"¿Se pueden colocar los herederos de una sealed class en diferentes archivos o paquetes? ¿Cómo afecta esto a la type-safety?"

Respuesta: No, todos los herederos directos de una sealed class deben estar definidos en un solo archivo. Este es un control del compilador para garantizar la type-safety. Si se colocan herederos en otros archivos de paquete, el compilador dará un error.

---

Ejemplos de errores reales debido a la falta de conocimiento sobre los detalles del tema

---

Historia

Al diseñar la lógica comercial de los pagos, se añadieron variantes de los resultados de la operación, olvidando actualizar la expresión when. Pero gracias a la sealed class, el compilador destacó los casos no considerados. En otro proyecto en Java, este escenario habría llevado a la inclusión de un estado no inicializado en el producto.

---

Historia

En un proyecto, después de migrar parte de los datos de sealed class a clases abiertas (open class) normales, las verificaciones exhaustive de when dejaron de funcionar: nuevos estados comenzaron a "perderse" en la lógica de manejo, lo que causó un comportamiento incorrecto en la interfaz.

---

Historia

En un sistema de e-commerce hubo un intento de optimizar la arquitectura moviendo los herederos de sealed class a archivos separados (cada uno en su propio módulo para reutilización). Esto rompió la compilación y causó una refactorización urgente antes del lanzamiento.