Una clase base genérica: extraer el patrón sin encadenarse a él

Hay un momento predecible en todo proyecto que implementa MVI a mano: la tercera pantalla. Las dos primeras se escriben con gusto, porque el patrón todavía se está aprendiendo y repetirlo enseña. En la tercera, copiar por tercera vez el mismo flujo privado, el mismo canal, la misma proyección y el mismo despacho deja de ser pedagógico y empieza a ser deuda, porque cada copia es un sitio donde el próximo cambio habrá que aplicar de nuevo y donde alguien podrá olvidarse. La respuesta natural es extraer el patrón a una clase base parametrizada por tres tipos. Es una buena respuesta y también una encrucijada: la clase base que hoy elimina duplicación es la misma que, si se deja crecer sin criterio, dentro de un año será el fichero que nadie se atreve a tocar porque de él cuelgan cuarenta pantallas.

Tres parámetros de tipo y ni uno más

La abstracción correcta tiene exactamente tres huecos, uno por cada vértice del triángulo: el estado que la pantalla publica, el vocabulario de intenciones que acepta y el vocabulario de efectos que produce. Cualquier parámetro adicional es casi siempre una responsabilidad que se ha colado.

abstract class BaseViewModel<S : Any, I : Any, E : Any>(
    estadoInicial: S,
) : ViewModel() {

    private val _estado = MutableStateFlow(estadoInicial)
    val estado: StateFlow<S> = _estado.asStateFlow()

    private val _efectos = Channel<E>(capacity = Channel.BUFFERED)
    val efectos: Flow<E> = _efectos.receiveAsFlow()

    protected val actual: S get() = _estado.value

    abstract fun procesar(intent: I)

    protected fun reducir(bloque: (S) -> S) = _estado.update(bloque)

    protected fun emitir(efecto: E) {
        _efectos.trySend(efecto).getOrElse { log.warn("efecto perdido: $efecto") }
    }

    override fun onCleared() {
        _efectos.close()
        super.onCleared()
    }
}

La cota superior en los tres parámetros no es decorativa. Sin ella, Kotlin admitiría tipos anulables, y un estado que pueda ser nulo destruye la garantía más valiosa del StateFlow: que siempre hay un valor renderizable. Restringir a un tipo no nulo cierra esa puerta en la definición y no en cada uso.

Los modificadores de visibilidad hacen aquí un trabajo silencioso pero decisivo. Las funciones de reducción y emisión son visibles para las subclases y no para el exterior, con lo que la única escritura posible del estado ocurre dentro de una pantalla concreta; el acceso al valor actual también es protegido, porque una interfaz que consulte el valor puntualmente en vez de observarlo estaría leyendo una foto que puede quedar obsoleta entre la lectura y el uso.

flowchart TD
B[BaseViewModel generico con estado intent y efecto] --> C[CarritoViewModel]
B --> S[BusquedaViewModel]
B --> P[PerfilViewModel]
B -.-> R[Aporta flujo privado canal y despacho]
C -.-> D[Aporta solo sus transiciones]
style B fill:#f9e2af,color:#11111b
style D fill:#a6e3a1,color:#11111b

Una pantalla concreta queda entonces reducida a lo que realmente le es propio: su tipo de estado, su vocabulario y sus transiciones. Todo lo demás desaparece del fichero.

class CarritoViewModel(
    private val repo: CarritoRepo,
) : BaseViewModel<CarritoState, CarritoIntent, CarritoEfecto>(CarritoState()) {

    override fun procesar(intent: CarritoIntent) = when (intent) {
        CarritoIntent.Cargar -> cargar()
        is CarritoIntent.Borrar -> borrar(intent.id)
    }

    private fun cargar() = viewModelScope.launch {
        reducir { it.copy(cargando = true) }
        val lineas = repo.lineas()
        reducir { it.copy(cargando = false, lineas = lineas) }
    }
}

Qué merece vivir en la base

La pregunta difícil no es cómo escribir la clase base, sino dónde detenerla. La regla que mejor resiste el paso del tiempo es que la base solo debe contener aquello que es idéntico para todas las pantallas y que forma parte del patrón, no del dominio ni de la conveniencia.

La columna del medio es donde se pierden los proyectos. Un manejador de errores común parece inofensivo y resuelve un caso real, pero exige que todos los estados tengan un campo de error, lo cual obliga a introducir una interfaz que todos los estados implementen, lo cual introduce un cuarto parámetro implícito y una jerarquía paralela. Al cabo de un año la clase base tiene doscientas líneas, seis responsabilidades y una subclase que hace una de ellas de forma distinta mediante una propiedad abierta que nadie recuerda por qué existe.

El síntoma diagnóstico es sencillo y conviene vigilarlo en cada revisión: si un cambio en la clase base obliga a mirar qué pantallas se ven afectadas antes de aceptarlo, la base ha dejado de ser un patrón compartido y se ha convertido en un acoplamiento compartido.

La alternativa por composición

La misma extracción admite una forma que no gasta la herencia: un objeto contenedor que encapsula el estado, el canal y sus proyecciones, y que la pantalla posee en vez de heredar. Es, esencialmente, lo que hacen las librerías serias del ecosistema, y no por casualidad.

class Contenedor<S : Any, E : Any>(
    estadoInicial: S,
    private val alcance: CoroutineScope,
) {
    private val _estado = MutableStateFlow(estadoInicial)
    val estado: StateFlow<S> = _estado.asStateFlow()

    private val _efectos = Channel<E>(capacity = Channel.BUFFERED)
    val efectos: Flow<E> = _efectos.receiveAsFlow()

    fun reducir(bloque: (S) -> S) = _estado.update(bloque)
    fun emitir(efecto: E) { _efectos.trySend(efecto) }
    fun lanzar(bloque: suspend () -> Unit) = alcance.launch { bloque() }
}

La pantalla declara entonces una propiedad de este tipo y delega en ella. Se gana ortogonalidad —la clase puede heredar de lo que quiera—, se gana testabilidad —el contenedor se prueba aislado, sin instanciar ninguna pantalla— y se gana la posibilidad de tener dos contenedores en un mismo componente cuando el caso lo justifica. Se pierde una pizca de concisión: hay que escribir el prefijo del contenedor en cada llamada, aunque una función delegada o una interfaz con implementación por delegación recupera casi toda la brevedad.