Inyectar en el ViewModel: el constructor como contrato

Hay dos maneras de que un ViewModel obtenga lo que necesita, y la diferencia entre ambas parece cosmética hasta que se examina lo que cada una comunica. En la primera, el objeto declara en su constructor todo aquello sin lo cual no puede existir, y quien lo construye está obligado a proporcionarlo; el resultado es que la firma dice la verdad y que un objeto mal ensamblado es imposible de crear. En la segunda, el objeto se construye vacío y va a buscar sus colaboradores a un registro accesible desde cualquier punto del programa; el resultado es que la firma calla, que el objeto arrastra una dependencia invisible con el registro entero y que un ensamblaje incorrecto no se detecta al construirlo sino más tarde, cuando alguien toca la parte que faltaba. Esta lección explica por qué la primera es preferible casi siempre y qué hacer en los pocos casos donde parece que no lo es.

La firma que no puede mentir

Un constructor es la única parte de una clase que el compilador obliga a satisfacer. Todo lo que aparece ahí es, por construcción, un requisito verificado; todo lo que no aparece es opcional, aunque el cuerpo lo use.

@HiltViewModel
class PedidoViewModel @Inject constructor(
    private val repositorio: RepositorioPedidos,
    private val calcularEnvio: CalcularEnvio,
    private val reloj: Reloj,
) : ViewModel(), ContainerHost<PedidoState, PedidoEfecto> {

    override val container = container<PedidoState, PedidoEfecto>(PedidoState())

    fun confirmar() = intent {
        reduce { state.copy(enviando = true) }
        val envio = calcularEnvio(state.lineas)
        val pedido = repositorio.crear(state.lineas, envio, reloj.ahora())
        reduce { state.copy(enviando = false, confirmado = pedido.id) }
        postSideEffect(PedidoEfecto.IrAResumen(pedido.id))
    }
}

Tres líneas de firma comunican más que cualquier documentación: esta pantalla habla con una fuente de pedidos, calcula portes y consulta la hora. Ese último punto merece énfasis porque suele olvidarse. Reloj no es una abstracción gratuita ni una manía purista: mientras el código llame directamente a la hora del sistema, el comportamiento del contenedor depende de cuándo se ejecuta el test, y hay reglas de negocio —descuentos que caducan, franjas horarias de reparto— cuyo test solo es reproducible si el tiempo es una dependencia declarada.

El localizador y por qué seduce

El localizador de servicios es el patrón en el que el objeto pide sus colaboradores a un registro accesible globalmente. Su atractivo es real: no hay que tocar constructores, no hay que propagar nada por las capas intermedias y añadir una dependencia nueva cuesta una línea dentro del cuerpo.

// Antipatron: la clase busca en vez de recibir
class PedidoViewModel : ViewModel() {
    private val repositorio = ServiceLocator.get<RepositorioPedidos>()
    private val calcularEnvio = ServiceLocator.get<CalcularEnvio>()
}

// Correcto: la clase declara y recibe
class PedidoViewModel(
    private val repositorio: RepositorioPedidos,
    private val calcularEnvio: CalcularEnvio,
) : ViewModel()

flowchart LR
subgraph Localizador
  L1[ViewModel] --> L2[Registro global]
  L2 --> L3[Repositorio]
  L2 --> L4[Calculo de envio]
end
subgraph Constructor
  C1[Raiz de composicion] --> C2[ViewModel]
  C1 --> C3[Repositorio]
  C1 --> C4[Calculo de envio]
end
style L2 fill:#f38ba8,color:#11111b
style C1 fill:#a6e3a1,color:#11111b

El diagrama expone la diferencia estructural: con el localizador, la flecha sale del ViewModel hacia el registro, de modo que la clase depende del mecanismo de resolución y, a través de él, de todo lo registrado. Con el constructor, las flechas salen de la raíz hacia las hojas y el ViewModel no conoce a nadie por encima de sí mismo. El primer grafo tiene un nodo por el que pasa todo; el segundo no tiene ningún punto de acoplamiento común.

Argumentos de navegación y dependencias con datos

Hay dos situaciones donde el constructor parece insuficiente, y ambas tienen solución sin abrir la mano.

La primera es el identificador que llega por navegación. La tentación es un método inicializar que se llama desde la interfaz, pero eso crea una ventana en la que el ViewModel existe con estado inválido y depende de que alguien recuerde llamarlo. La solución correcta es SavedStateHandle, que el framework provee al grafo y que llega con los argumentos ya dentro.

@HiltViewModel
class DetalleViewModel @Inject constructor(
    private val repositorio: RepositorioPedidos,
    estadoGuardado: SavedStateHandle,
) : ViewModel(), ContainerHost<DetalleState, DetalleEfecto> {

    private val pedidoId: String = checkNotNull(estadoGuardado["pedidoId"])

    override val container = container<DetalleState, DetalleEfecto>(DetalleState(pedidoId)) {
        cargar()
    }

    private fun cargar() = intent {
        val pedido = repositorio.obtener(pedidoId)
        reduce { state.copy(pedido = pedido) }
    }
}

La segunda situación es una dependencia que solo se puede construir con un dato conocido en ejecución. Aquí caben dos respuestas legítimas. Si el dato acompaña a una operación concreta, pasa a ser un parámetro de esa operación y desaparece del problema. Si de verdad hace falta construir un colaborador con ese dato, se inyecta una fábrica —una interfaz con un método que recibe el dato y devuelve el colaborador—, con lo que la dependencia sigue declarada y sigue siendo sustituible.