Koin: el grafo declarado en Kotlin y resuelto en ejecución

Koin parte de una intuición que merece respeto: si Kotlin ya es un lenguaje expresivo con funciones de orden superior, receptores y lambdas con contexto, quizá no haga falta un lenguaje de anotaciones encima ni un procesador que lo traduzca. El grafo de dependencias es, al fin y al cabo, un conjunto de recetas para construir objetos, y eso se puede escribir directamente como código. La consecuencia es un DSL que se lee casi como prosa, sin generación intermedia, sin tiempos de compilación penalizados y sin errores crípticos escupidos por un procesador. La contrapartida es exacta y hay que enunciarla sin adornos: lo que Hilt te demuestra antes de ejecutar, Koin te lo descubre al pedirlo. No es que uno sea correcto y el otro no; es que cada uno decide en qué momento del ciclo de vida del proyecto quiere pagar la factura de sus errores.

El grafo escrito como código

Un módulo de Koin no es un fichero de configuración ni una clase anotada: es una función que devuelve una lista de definiciones, y por tanto se puede componer, parametrizar y leer de arriba abajo sin descifrar ninguna convención.

val redModule = module {
    single { OkHttpClient.Builder().build() }
    single<PerfilApi> {
        Retrofit.Builder()
            .baseUrl("https://api.example.com")
            .client(get())
            .build()
            .create(PerfilApi::class.java)
    }
}

val datosModule = module {
    single<RepositorioPerfil> { RepositorioHttp(api = get()) }
    factory { MapeadorPerfil() }
}

class Aplicacion : Application() {
    override fun onCreate() {
        super.onCreate()
        startKoin {
            androidContext(this@Aplicacion)
            modules(redModule, datosModule, presentacionModule)
        }
    }
}

La llamada a get es el corazón del mecanismo: dentro de una definición, get resuelve otra definición por su tipo. Como el DSL es Kotlin normal, la inferencia de tipos hace casi todo el trabajo, y el parámetro de tipo explícito —single<RepositorioPerfil>— sirve para registrar la implementación bajo el contrato y no bajo su clase concreta, que es justo la inversión que se busca.

La diferencia entre single y factory es de ciclo de vida y no de rendimiento: single construye una vez y devuelve siempre la misma instancia mientras viva el contenedor raíz; factory construye una nueva en cada petición. El criterio para elegir es el mismo de siempre: si el objeto guarda estado que debe compartirse, single; si no guarda estado o su estado es privado de quien lo pide, factory.

Dónde y cuándo estalla lo que falta

Aquí está la diferencia sustantiva con el enfoque de compilación, y conviene verla con precisión temporal en vez de en abstracto.

flowchart LR
A[Compilacion: el DSL solo es codigo valido] --> B[Arranque: startKoin registra definiciones]
B --> C[Primera peticion: se resuelve el tipo]
C --> D{Existe definicion}
D -->|si| E[Objeto construido]
D -->|no| F[NoDefinitionFoundException en ejecucion]
style A fill:#89b4fa,color:#11111b
style F fill:#f38ba8,color:#11111b
style E fill:#a6e3a1,color:#11111b

El detalle crítico es que startKoin no valida el grafo: registra definiciones. Una dependencia sin proveedor no falla al arrancar, falla cuando alguien la pide por primera vez, es decir, cuando el usuario abre esa pantalla concreta. Si esa pantalla está detrás de tres navegaciones y de un permiso, el fallo puede llegar a producción con toda naturalidad, porque nadie del equipo recorrió ese camino después del último cambio de módulos.

Ámbitos y el contenedor MVI

Koin también tiene ámbitos, aunque su naturaleza es distinta: no forman una jerarquía fijada por el framework, sino que se abren y se cierran explícitamente asociados a un objeto. Para el caso de MVI, lo habitual es apoyarse en la integración de ViewModel, que ya conoce el ciclo de vida de Android.

val presentacionModule = module {
    viewModel { PerfilViewModel(repositorio = get()) }
    // Version reflexiva equivalente, mas breve y menos explicita
    viewModelOf(::AjustesViewModel)

    scope<SesionCompra> {
        scoped { CarritoEnMemoria() }
        scoped<CalculadoraTotales> { CalculadoraImpl(carrito = get()) }
    }
}

class PerfilViewModel(
    private val repositorio: RepositorioPerfil,
) : ViewModel(), ContainerHost<PerfilState, PerfilEfecto> {

    override val container = container<PerfilState, PerfilEfecto>(PerfilState())

    fun cargar() = intent {
        reduce { state.copy(cargando = true) }
        val perfil = repositorio.obtener()
        reduce { state.copy(cargando = false, perfil = perfil) }
    }
}

En Compose, la obtención se hace con koinViewModel, simétrica a hiltViewModel, y el contenedor queda ligado al ciclo de vida del propietario del ViewModel igual que en el otro enfoque. Obsérvese que la clase del ViewModel no lleva ninguna anotación: es una clase de Kotlin corriente cuyo constructor pide lo que necesita. Esa neutralidad es una de las propiedades más subestimadas de Koin, porque significa que la lógica de presentación no importa nada del framework de inyección y puede construirse a mano en cualquier test sin ceremonia adicional.

El criterio de elección

La comparación honesta no enfrenta a un ganador con un perdedor, sino a dos posiciones sobre cuándo pagar. Koin cobra menos en la construcción y en la curva de entrada, y más en la superficie de fallos que llegan a ejecución. Hilt cobra más por adelantado —procesador, verbosidad, mensajes de error densos— y devuelve una demostración sobre el grafo entero.

Hay tres factores que inclinan la decisión mucho más que la preferencia estética. El primero es el tamaño del grafo: por debajo de unas pocas decenas de definiciones, la probabilidad de una arista rota que nadie ejecute es baja, y la garantía estática vale poco. El segundo es la rotación del equipo: donde entra gente nueva a menudo, la verificación al compilar sustituye al conocimiento tribal sobre qué módulo instala qué. El tercero es la multiplataforma: Koin funciona en Kotlin Multiplatform y Hilt está atado a Android y a la JVM, de modo que si el módulo de dominio debe compartirse con iOS la decisión ya está tomada por razones ajenas al debate.