为何Android MVI CoroutineFlow项目用filterIsInstance而非when？

在MVI架构的ViewModel实现中，开发者采用merge结合filterIsInstance的方式处理ViewIntent流，替代了常见的when+flatMapLatest写法。以下是两种实现的对比，以及前者的核心优势：

两种实现对比 #

使用filterIsInstance+merge的实现 #

private fun SharedFlow<ViewIntent>.toPartialStateChangeFlow(): Flow<PartialStateChange> =
    merge(
      // users change
      merge(
        filterIsInstance<ViewIntent.Initial>(),
        filterIsInstance<ViewIntent.Retry>()
          .filter { viewState.value.error != null },
      ).toUserChangeFlow(),
      // refresh change
      filterIsInstance<ViewIntent.Refresh>()
        .toRefreshChangeFlow(),
      // remove user change
      filterIsInstance<ViewIntent.RemoveUser>()
        .toRemoveUserChangeFlow(),
    )

未采用的when写法（修正语法错误后） #

private fun SharedFlow<ViewIntent>.toPartialStateChangeFlow(): Flow<PartialStateChange> =
    flatMapLatest { intent ->
      when (intent) {
        is ViewIntent.Initial, is ViewIntent.Retry -> {
          if (intent is ViewIntent.Retry && viewState.value.error == null) {
            emptyFlow()
          } else {
            toUserChangeFlow()
          }
        }
        is ViewIntent.Refresh -> toRefreshChangeFlow()
        is ViewIntent.RemoveUser -> toRemoveUserChangeFlow()
        else -> emptyFlow()
      }
    }

选择filterIsInstance+merge的核心优势 #

• 逻辑拆分更清晰，职责单一
  每种ViewIntent的处理逻辑被拆分成独立的流分支，比如Initial和Retry合并后统一交给toUserChangeFlow，Refresh单独对应toRefreshChangeFlow，结构一目了然。维护时无需在庞大的when块中查找对应逻辑，每个分支只关注自身的过滤与转换规则。

• 贴合Flow的响应式设计思想
  Flow本身基于声明式流式处理，filterIsInstance+merge完全用Flow操作符串联逻辑，避免了在flatMapLatest中嵌套条件判断，更符合响应式编程的风格，代码的声明性更强。

• 条件过滤更灵活直观
  对于Retry这类需要额外条件（viewState.value.error != null）的场景，可直接在对应流分支上追加filter操作，无需在when块里嵌套if判断。同时能轻松合并多个相似意图的流，统一处理逻辑。

• 扩展性更好，符合开闭原则
  新增ViewIntent类型时，只需新增一个filterIsInstance分支并merge进去即可，无需修改原有代码块；而when写法需要在原有分支中新增case，容易影响原有逻辑的稳定性。

• 减少嵌套层级，提升可读性
  原when写法需要在分支内嵌套if判断处理Retry的额外条件，流式写法通过操作符链式调用完成逻辑，无嵌套结构，代码更简洁易读。

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