Kotlin Sealed Classes（密封类）实用场景及相关技术疑问

1. 密封类的实际应用实例有哪些？ #

• 网络请求状态封装：最常用的场景，统一处理请求的不同状态，确保所有分支都被覆盖：

sealed class NetworkResult<out T> {
    data class Success<out T>(val data: T) : NetworkResult<T>()
    data class Error(val exception: Exception) : NetworkResult<Nothing>()
    object Loading : NetworkResult<Nothing>()
}

// 使用示例
fun handleUserResult(result: NetworkResult<User>) {
    when(result) {
        is NetworkResult.Success -> renderUser(result.data)
        is NetworkResult.Error -> showErrorToast(result.exception.message)
        NetworkResult.Loading -> showLoadingSpinner()
    }
}

• UI状态管理：比如页面的空数据、正常加载、错误提示状态，或者按钮的选中、未选中、禁用状态。
• 表达式树（AST）：在编译或语法解析场景中，用密封类表示不同类型的表达式节点（加减乘除、变量、常量），遍历节点时能确保覆盖所有类型。
• 业务操作结果封装：比如处理用户操作的结果（成功、参数错误、权限不足、系统异常），统一返回类型，避免零散的返回值。

2. 若实现类未被密封则可被进一步继承，该特性有何用途？ #

Kotlin密封类的子类默认是open的（除非加final修饰），允许继承的核心价值是在保留密封类穷尽性检查的前提下，灵活扩展业务场景：

• 业务定制化扩展：比如基础的NetworkResult可以扩展出CachedSuccess子类，专门处理缓存命中的场景，同时不破坏原有when分支的完整性：

// 同一文件/模块内扩展
data class CachedSuccess<out T>(val data: T, val cacheTimestamp: Long) : NetworkResult.Success<T>(data)

• 模块化复用：在多模块项目中，密封类定义在基础模块，业务模块可按需扩展子类，既保证基础类型约束，又满足定制需求。
• 逻辑复用：通过继承密封类的子类，可复用父类的逻辑，比如Success已实现数据持有，CachedSuccess只需新增缓存时间字段即可。

3. 密封类是否与Java的default修饰符作用相同？ #

完全不同，二者属于不同维度的特性：

• Java的default是访问修饰符，用于限制类、方法、字段的访问范围，仅同一包内的代码可访问，核心是控制可见性。
• Kotlin密封类是继承约束机制，限制子类只能在密封类所在文件（Kotlin 1.5前）或同一模块（Kotlin 1.5及后）中定义，核心是保证类型集合的有限性，让when表达式能做到穷尽性检查，和访问权限无直接关联。

4. 除when条件分支场景外，密封类的实际应用场景及适用时机是什么？ #

• 领域模型的有限类型集合：当业务概念只有固定几种类型，且不希望外部随意扩展时，比如订单状态（待支付、已支付、已取消）、物流状态（运输中、已签收、派送中），用密封类可确保所有合法状态都被覆盖，避免非法状态出现。
• 状态机实现：比如UI状态流转、设备状态管理，每个状态对应密封类的一个子类，状态转换时能明确处理所有输入状态，避免遗漏分支导致逻辑错误。
• 依赖注入的多态约束：比如定义DataSource密封类，子类包括LocalDbSource、RemoteApiSource、MemoryCacheSource，注入时可统一约束数据源类型，同时允许扩展新实现。
• 消息/事件总线的事件类型：App内部事件（用户登录、退出、更新信息）用密封类定义，确保事件消费者能处理所有可能的事件类型，避免未处理事件引发异常。
• 带参数的枚举替代：相比枚举，密封类的子类可携带不同参数（比如Success带数据、Error带异常），适合需要额外信息的有限类型场景，比枚举更灵活。

内容的提问来源于stack exchange，提问作者Jithin Murali