创建SharedFlow的函数是否暴露其特性？最佳实践探讨

在Kotlin协程中设计SharedFlow创建函数时，我们会遇到一个关键问题：到底该直接返回SharedFlow类型暴露其所有特性，还是封装成普通Flow返回以隐藏实现细节？下面结合示例代码和三种方案来分析：

fun CoroutineScope.createExposedSharedFlow(): SharedFlow<Int> {
    return flow<Int> { }.shareIn(this, started = SharingStarted.Lazily)
}

fun CoroutineScope.createEncapsulatedSharedFlow(): Flow<Int> {
    return flow<Int> { }.shareIn(this, started = SharingStarted.Lazily)
}

fun CoroutineScope.createEncapsulatedSharedFlow(onSubscription: suspend FlowCollector<Int>.() -> Unit): Flow<Int> {
    return flow<Int> { }.shareIn(this, started = SharingStarted.Lazily).onSubscription(onSubscription)
}

suspend fun useFlows() = coroutineScope {
    createExposedSharedFlow().onSubscription {
        // 可以正常使用onSubscription
    }

    createEncapsulatedSharedFlow().onSubscription {
        // 无法编译，因为普通Flow没有这个方法
    }

    createEncapsulatedSharedFlow {
        // 通过参数传入，正常执行
    }
}

三种方案的优劣势分析 #

方案1：完全暴露SharedFlow #

直接返回SharedFlow类型，调用方可以随意使用onSubscription、replayCache等专属API，灵活性拉满。但问题也很明显——你把内部实现细节彻底暴露了，如果后续想把SharedFlow换成StateFlow或者自定义Flow，调用方那些依赖了SharedFlow特性的代码会直接报错，完全没有封装性可言。

方案2：完全封装为普通Flow #

返回普通Flow，彻底隐藏了内部是SharedFlow的事实。这样做保证了封装性和未来的可扩展性，后续更换实现不会影响调用方。但代价是调用方没法使用任何SharedFlow专属功能，如果业务需要监听订阅事件这类操作，就完全没办法了，灵活性太差。

方案3：封装为普通Flow，通过参数开放必要特性 #

依然返回Flow，但把调用方需要的SharedFlow专属功能（比如onSubscription）通过函数参数的形式开放出来。这种方式完美平衡了封装性和实用性：既没暴露内部实现，又让调用方能够用到需要的特性。就算后续要更换Flow实现，只需要调整函数内部对参数的处理逻辑，调用方代码完全不用改。

最佳实践 #

大多数场景下，方案3是最稳妥的选择。如果你的API明确要最大化灵活性，且确定后续不会更换SharedFlow实现，可以考虑方案1；如果调用方完全不需要SharedFlow的专属特性，或者你想彻底隔离内部实现，方案2也没问题。但总体来说，方案3的平衡策略适配绝大多数业务场景。

内容的提问来源于stack exchange，提问作者Tobias Marschall