Diseñar con contexto: cuándo es la herramienta correcta y cuándo es magia

Las cuatro lecciones anteriores describen un mecanismo con reglas nítidas y sin sorpresas: se declara con nombre, se resuelve por tipo del ámbito interno al externo, habilita llamadas y no las despacha, y se compila como un parámetro más. Todo lo que queda es la parte difícil, que no es técnica. Un parámetro de contexto es tan cómodo de declarar que se declarará de más, y su coste no aparece el día que se escribe sino dos años después, cuando alguien abra una función, lea una llamada perfectamente limpia y tenga que reconstruir mentalmente cuatro niveles de ámbito para saber qué transacción se está usando. La pregunta que cierra el nivel no es cómo se usan los contextos, sino qué merece ser contexto, y la respuesta correcta es que muy pocas cosas.

Tres preguntas antes de declarar un contexto

Conviene empezar por el sesgo por defecto, porque establecerlo bien ahorra la mitad de las discusiones. El sesgo por defecto es no: un valor es un parámetro ordinario salvo que demuestre lo contrario, igual que una clase es final salvo que se declare open y un tipo no admite nulo salvo que se marque. Kotlin ha tomado esa misma decisión en todos los ejes donde la comodidad y la seguridad se oponen, y no hay ninguna razón para invertirla aquí.

La primera pregunta es la de la irrelevancia semántica: ¿cambiaría el significado de la operación si este valor fuera otro? Un formateador de moneda distinto produce una cadena distinta pero no convierte la operación en otra operación; una moneda de destino distinta sí. Cuando el valor participa en lo que la función significa, es un parámetro y quien llama debe escribirlo, aunque escribirlo cueste. Cuando el valor solo determina cómo se hace algo que se haría igual sin él, es candidato a contexto.

La segunda es la de la regionalidad: ¿existe una región del programa dentro de la cual este servicio es el mismo para todas las llamadas? Una transacción cumple, porque hay un bloque con principio y fin y todo lo de dentro pertenece a la misma unidad de trabajo. Un identificador de usuario que cambia en cada iteración de un bucle no cumple, y forzarlo a contexto obliga a abrir un ámbito por iteración, que es una forma cara y confusa de escribir un argumento.

La tercera es la de la transversalidad: ¿lo necesitan muchas funciones que no tienen nada que ver entre sí? Si el servicio lo usan tres funciones del mismo archivo, la respuesta correcta casi siempre es una clase con ese servicio como campo. El contexto se justifica cuando el conjunto de funciones que lo necesitan atraviesa módulos y no admite un hogar común, que es la situación de la observabilidad, de los ámbitos de recurso y de la localización.

Las tres preguntas hay que pasarlas en ese orden y las tres tienen que dar la respuesta favorable, porque cada una filtra un error distinto y ninguna cubre a las otras. Un identificador de petición pasa la primera y la tercera pero suspende la segunda si cambia dentro del bucle; un repositorio pasa la primera y la segunda y suspende la tercera porque tiene un hogar evidente. Solo lo que sobrevive a las tres es contexto, y la lista de cosas que sobreviven es notablemente corta: en un proyecto sano cabe en los dedos de una mano.

// Suspende la primera: la moneda cambia el resultado, es un argumento
fun convertir(importe: Dinero, destino: Moneda): Dinero

// Suspende la segunda: cambia en cada iteracion, no delimita ninguna region
fun procesarUsuario(id: UsuarioId, datos: Datos): Resultado

// Pasa las tres: transversal, regional y semanticamente irrelevante
context(tx: Transaccion)
fun guardar(datos: Datos): Unit

Frente al parámetro y frente a la inyección de dependencias

Un efecto secundario agradable de este mecanismo, y que conviene tener en cuenta al valorar la decisión, es que mejora la comprobabilidad en lugar de empeorarla. Una prueba que quiera sustituir el servicio abre su propio ámbito con un doble y lo cierra al terminar, sin tocar ningún estado compartido y sin coordinarse con ninguna otra prueba, de modo que la ejecución en paralelo deja de ser un riesgo. Es exactamente lo contrario de lo que ocurre con un singleton mutable, y por sí solo justifica migrar los servicios ambientales que hoy vivan ahí.

La comparación con el parámetro ordinario ya está hecha por las tres preguntas, pero conviene explicitar la asimetría de costes, porque no es simétrica en absoluto. Convertir un parámetro en contexto ahorra caracteres en cada llamada y cuesta visibilidad en todas ellas; convertir un contexto en parámetro cuesta caracteres y no pierde nada más que comodidad. Por tanto el sesgo por defecto tiene que ser el parámetro, y el contexto debe ganarse su lugar demostrando que el ruido que elimina es real y masivo. Diez llamadas no lo justifican; una dependencia que atraviesa treinta firmas intermedias que no la usan, sí.

La comparación con la inyección de dependencias por constructor es más sutil, y el error habitual es plantearla como una competición. No lo es, porque resuelven problemas que solo se parecen por fuera. La inyección por constructor construye un grafo de objetos y fija dependencias para todo el tiempo de vida de una instancia; el contexto delimita una región de ejecución y no tiene nada que ver con ningún tiempo de vida. De hecho el propio lenguaje impide confundirlos, porque los contextos no se pueden declarar sobre clases ni sobre constructores.

// Dependencia de identidad: vive con el objeto, va por constructor
class ServicioPedidos(private val repo: RepositorioPedidos) {

    // Dependencia de region: vive con la llamada, va por contexto
    context(tx: Transaccion, log: Logger)
    fun confirmar(id: String): Confirmacion {
        log.info("confirmando $id")
        return tx.dentro { repo.marcarConfirmado(id) }
    }
}

Hay una prueba mecánica que zanja casi todos los casos dudosos y que conviene tener a mano: pregúntate si dos llamadas consecutivas al mismo método de la misma instancia podrían necesitar legítimamente valores distintos. Si la respuesta es no, la dependencia pertenece al objeto y el constructor es su sitio; el compilador ni siquiera te dejaría hacer otra cosa, porque los contextos no se declaran sobre clases. Si la respuesta es sí, has descubierto que lo que creías una propiedad del objeto era en realidad una propiedad del momento en que se le llama, y ese descubrimiento suele deshacer nudos de diseño que llevaban años ahí.

La regla que se deriva es fácil de recordar y bastante fiable: si la dependencia no cambia mientras el objeto exista, es de identidad y va por constructor; si cambia con la región de ejecución y puede ser distinta en dos llamadas al mismo objeto, es de ámbito y va por contexto. Un repositorio pertenece al primer grupo; una transacción, un ámbito de corrutina y una localización pertenecen al segundo. El contexto complementa a la inyección justo donde esta no llega, que en Kotlin idiomático es un territorio grande: las funciones de nivel superior, las funciones de extensión y todo el código sin estado que no quiere ser una clase.

flowchart TD
A[Una funcion necesita un valor] --> B{Cambia el significado de la operacion}
B -- Si --> P[Parametro ordinario]
B -- No --> C{Es el mismo en toda una region}
C -- No --> P
C -- Si --> D{Vive con un objeto o con la llamada}
D -- Con el objeto --> E[Constructor]
D -- Con la llamada --> F[Parametro de contexto]

El riesgo de la magia implícita

Antes de enumerar los síntomas conviene reconocer con honestidad qué se pierde al usar el mecanismo bien, porque incluso el uso correcto tiene un coste y fingir lo contrario no ayuda a nadie. Se pierde la lectura local: para saber qué transacción usa una línea hay que salir de ella y buscar hacia arriba. Se pierde parte del contenido informativo del diff, porque un cambio en la función que abre el ámbito altera el comportamiento de código que no aparece en el cambio. Y se pierde inmediatez en el diagnóstico de errores de configuración, ya que el compilador señala el sitio de llamada mientras la causa suele estar varios niveles por encima. Ninguna de las tres es grave, y las tres se agravan de forma no lineal con la cantidad de contextos, que es exactamente la razón por la que la disciplina importa aquí más que en cualquier otra característica del lenguaje.

Los cinco síntomas de abuso son reconocibles y aparecen casi siempre juntos. El primero es el tipo general como contexto: en cuanto veas un contexto de tipo String o Map, hay un parámetro escondido y habrá ambigüedades. El segundo es la pila profunda de contextos, tres o más declarados a la vez en firmas repartidas por el proyecto, que convierte cada llamada en una consulta a cuatro ámbitos distintos. El tercero es el contexto que se usa una sola vez en toda la cadena, señal de que el ámbito no describe nada y solo evita escribir un argumento. El cuarto es la dependencia oculta en la API pública: publicar una función con contexto obliga a todo cliente a construir ese ámbito, y si el tipo del contexto no es evidente, la biblioteca resulta imposible de empezar a usar. El quinto es el contexto mutable, que reintroduce por la puerta de atrás todos los problemas del estado global y anula la única ventaja seria del mecanismo, que era ser estático y verificable.

De los cinco, el segundo y el cuarto son los que más silenciosamente destruyen una base de código, porque ninguno de los dos produce error alguno: el proyecto compila, las pruebas pasan y el problema solo se manifiesta como una lentitud creciente en la incorporación de gente nueva y en el tiempo que cuesta responder a la pregunta más simple posible sobre una línea cualquiera. Cuando notes que para explicar una función tienes que empezar diciendo depende de dónde la llames, ya has cruzado la frontera.

La contramedida más eficaz para el cuarto síntoma es un patrón de una sola línea que toda biblioteca que exija contexto debería ofrecer: una función de entrada que construya el ámbito, lo provea y lo cierre, de modo que el cliente nunca tenga que averiguar por su cuenta cómo se monta.

// La biblioteca provee la puerta; el cliente no monta nada a mano
fun <R> enTransaccion(fuente: FuenteDatos, bloque: Transaccion.() -> R): R {
    val tx = fuente.abrir()
    try {
        val resultado = tx.bloque()   // el receptor sirve de argumento de contexto
        tx.confirmar()
        return resultado
    } catch (e: Throwable) {
        tx.deshacer()
        throw e
    }
}

// Y dentro del bloque todo lo que exija Transaccion resuelve solo
val total = enTransaccion(fuente) { guardar(datos); calcularTotal() }

Esa función hace tres cosas a la vez y las tres importan: documenta con su nombre cuál es la región, garantiza que el recurso se cierra pase lo que pase, y convierte una exigencia difusa de la API en una llamada que el cliente encuentra sin leer nada. Cuando una biblioteca exige contexto y no ofrece su puerta de entrada, el trabajo de montar el ámbito se ha externalizado a todos sus usuarios a la vez.