如何在不暴露MutableStateFlow的前提下提取ViewModel逻辑至独立文件？

ViewModel中存在大量需要检查并更新StateFlow状态的代码，想要把这部分代码提取到独立类中，但又不希望暴露MutableStateFlow，只传StateFlow过去又没法更新状态，请问最简洁的实现方式是什么？

// 文件: MyViewModel.kt
package com.example.viewmodel

import kotlinx.coroutines.flow.MutableStateFlow
import kotlinx.coroutines.flow.asStateFlow

@HiltViewModel    
class MyViewModel : ViewModel() {
    private val _state = MutableStateFlow(STATE.INITIAL)
    val state = _state.asStateFlow()

    // TODO: 如何将此代码提取至独立文件/类/对象
    fun doSomething() {
        if(state.value == STATE.INITIAL) {
            startConnection() {
               // 出错时：
               _state.value = STATE.ERROR
            }
            _state.value = STATE.CONNECTING
        }
    }
}

最简洁的实现思路是让业务类只负责逻辑判断与执行，把状态更新的控制权留在ViewModel中，以下是几种落地方案：

方案1：传入状态更新Lambda（最简） #

直接把状态更新的逻辑以Lambda形式传给业务类，业务类无需感知MutableStateFlow，只在需要时调用Lambda更新状态。

// 独立业务类：ConnectionHandler.kt
class ConnectionHandler {
    fun handleConnection(
        currentState: STATE,
        onStateChange: (STATE) -> Unit,
        startConnection: (onError: () -> Unit) -> Unit
    ) {
        if (currentState == STATE.INITIAL) {
            startConnection {
                onStateChange(STATE.ERROR)
            }
            onStateChange(STATE.CONNECTING)
        }
    }
}

// 修改后的MyViewModel.kt
@HiltViewModel    
class MyViewModel : ViewModel() {
    private val _state = MutableStateFlow(STATE.INITIAL)
    val state = _state.asStateFlow()
    private val connectionHandler = ConnectionHandler()

    fun doSomething() {
        connectionHandler.handleConnection(
            currentState = state.value,
            onStateChange = { _state.value = it },
            startConnection = this::startConnection
        )
    }

    private fun startConnection(onError: () -> Unit) {
        // 原有的连接逻辑实现
    }
}

方案2：定义状态更新接口（适合多操作场景） #

如果业务类需要触发多种状态更新，可定义一个接口封装更新逻辑，ViewModel实现该接口后传给业务类，结构更清晰。

// 定义状态更新接口
interface StateUpdater {
    fun updateState(newState: STATE)
}

// 业务类
class ConnectionHandler(private val updater: StateUpdater) {
    fun handleConnection(
        currentState: STATE,
        startConnection: (onError: () -> Unit) -> Unit
    ) {
        if (currentState == STATE.INITIAL) {
            startConnection {
                updater.updateState(STATE.ERROR)
            }
            updater.updateState(STATE.CONNECTING)
        }
    }
}

// ViewModel实现接口
@HiltViewModel    
class MyViewModel : ViewModel(), StateUpdater {
    private val _state = MutableStateFlow(STATE.INITIAL)
    val state = _state.asStateFlow()
    private val connectionHandler = ConnectionHandler(this)

    fun doSomething() {
        connectionHandler.handleConnection(state.value, this::startConnection)
    }

    private fun startConnection(onError: () -> Unit) {
        // 原有的连接逻辑实现
    }

    override fun updateState(newState: STATE) {
        _state.value = newState
    }
}

方案3：状态管理委托类（复杂状态场景） #

如果状态本身的读写逻辑也很复杂，可以把状态管理封装成独立类，业务类依赖这个委托类完成状态检查与更新，ViewModel只暴露只读的StateFlow给外部。

// 状态管理委托类
class StateManager {
    private val _state = MutableStateFlow(STATE.INITIAL)
    val state = _state.asStateFlow()

    fun getCurrentState() = state.value
    fun updateState(newState: STATE) {
        _state.value = newState
    }
}

// 业务类
class ConnectionHandler(private val stateManager: StateManager) {
    fun handleConnection(startConnection: (onError: () -> Unit) -> Unit) {
        if (stateManager.getCurrentState() == STATE.INITIAL) {
            startConnection {
                stateManager.updateState(STATE.ERROR)
            }
            stateManager.updateState(STATE.CONNECTING)
        }
    }
}

// ViewModel中使用委托类
@HiltViewModel    
class MyViewModel : ViewModel() {
    private val stateManager = StateManager()
    val state = stateManager.state
    private val connectionHandler = ConnectionHandler(stateManager)

    fun doSomething() {
        connectionHandler.handleConnection(this::startConnection)
    }

    private fun startConnection(onError: () -> Unit) {
        // 原有的连接逻辑实现
    }
}

方案选择建议 #

• 简单场景选方案1，无需额外定义接口/类，代码量最少；
• 多状态更新操作选方案2，接口定义更清晰，扩展性更强；
• 复杂状态管理场景选方案3，彻底分离状态管理与业务逻辑，维护性更好。

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