Objetos y estado global: el precio del singleton

Escribir object es la forma más barata que ofrece Kotlin de crear una variable global, y la baratura es precisamente el problema. En un lenguaje sin la palabra clave, montar un singleton exige el suficiente trabajo como para que alguien se pregunte en voz alta si hace falta; aquí sale gratis y nadie pregunta nada. El resultado se ve en muchas bases de código maduras: una capa de objetos que empezaron siendo un contenedor inocente de funciones auxiliares y acabaron guardando cachés, clientes de red, configuración y banderas, todo ello invisible en las firmas y vivo durante toda la ejecución del proceso. Este nivel cierra con la parte que no es sintaxis, sino ingeniería: qué se paga por cada object con estado, por qué las pruebas son el primer sitio donde se nota, y cuál es el criterio para saber si estabas resolviendo un problema o evitando pensar.

Lo que un objeto con estado se lleva por delante

El primer coste es de tiempo de vida. La instancia cuelga de un campo estático de una clase cargada por el cargador de la aplicación, que en la práctica no se descarga nunca, así que el objeto y todo lo que él referencia son raíces vivas del recolector hasta que el proceso termine. Una caché en un object sin política de expulsión no es una caché: es una fuga con buena reputación.

El segundo es de acoplamiento. Una función que consulta un object global tiene una dependencia que no aparece en su firma, y eso destruye la propiedad más útil de una firma, que es poder leer lo que una función necesita sin leer su cuerpo. Dos funciones con la misma firma pueden depender una de un reloj y otra de una base de datos, y nadie lo sabrá hasta abrirlas.

El tercero es de concurrencia. La máquina virtual garantiza que la creación del singleton es segura, no que su estado lo sea. Un var público en un object compartido es exactamente el mismo problema que cualquier campo mutable compartido, con el agravante de que el acceso está disponible desde cualquier punto del programa sin necesidad de pasar ninguna referencia.

object Contadores {
    var peticiones = 0            // carrera de datos garantizada
    val porRuta = mutableMapOf<String, Int>()   // ademas, mapa no seguro
}

// La version defendible del mismo objeto
object ContadoresSeguros {
    private val peticiones = java.util.concurrent.atomic.AtomicLong()
    private val porRuta = java.util.concurrent.ConcurrentHashMap<String, Long>()

    fun registra(ruta: String) {
        peticiones.incrementAndGet()
        porRuta.merge(ruta, 1L, Long::plus)
    }

    fun instantanea(): Map<String, Long> = porRuta.toMap()
}

flowchart LR
O[Declaracion object con estado mutable] --> V[Vive mientras viva el cargador de clases]
O --> A[Dependencia ausente de todas las firmas]
O --> H[Acceso concurrente sin coordinacion por defecto]
V --> P[Retencion de memoria y cachas sin expulsion]
A --> T[Pruebas acopladas y orden significativo]
H --> D[Carreras de datos dificiles de reproducir]
style P fill:#f38ba8,color:#11111b
style T fill:#f38ba8,color:#11111b
style D fill:#f38ba8,color:#11111b

Hay un cuarto coste, menos citado y a menudo el más caro de diagnosticar: el orden de inicialización. Como cada object nace en su primer uso, el orden en que nacen depende del camino de ejecución concreto, no de tu diseño. En cuanto dos singletons se leen mutuamente durante su construcción, el resultado deja de ser determinista desde el punto de vista del programa: según quién se toque primero, uno de los dos verá al otro a medio construir. Ese fallo se manifiesta con una propiedad no nula que vale nulo, sobrevive a las pruebas locales y aparece en producción con un arranque distinto.

Las pruebas son el detector de humos

El estado global no se nota mientras el programa se ejecuta una sola vez de principio a fin. Se nota cuando algo lo ejecuta muchas veces dentro del mismo proceso, y eso es exactamente lo que hace una batería de pruebas. Ahí aparecen los tres síntomas clásicos a la vez: pruebas que pasan solas y fallan en grupo, pruebas cuyo resultado depende del orden alfabético de sus nombres, y la imposibilidad de ejecutarlas en paralelo porque comparten un mapa mutable.

A eso se suma que un object se compila como clase final con constructor privado: no hay forma de sustituirlo por una implementación falsa sin manipular el bytecode con herramientas que reescriben la clase en tiempo de ejecución. Que exista esa posibilidad no la convierte en una buena idea; convierte en una necesidad algo que un diseño distinto no habría requerido.

La solución no es prohibir el object, sino separar dos cosas que se habían mezclado: el contrato y la implantación por defecto.

interface Reloj {
    fun ahora(): Instant
}

object RelojSistema : Reloj {
    override fun ahora(): Instant = Instant.now()
}

class Suscripcion(
    private val reloj: Reloj = RelojSistema,   // valor por defecto, no dependencia rigida
) {
    fun caducada(hasta: Instant): Boolean = reloj.ahora() > hasta
}

El truco está en el parámetro con valor por defecto. En producción nadie escribe nada y la comodidad del singleton se conserva íntegra; en una prueba se pasa un reloj fijo y el tiempo deja de ser un problema. La dependencia aparece en la firma del constructor, es decir, vuelve a ser información visible. Y el object sigue existiendo, pero ha bajado de categoría: de dependencia inevitable a cableado por defecto.

class RelojFijo(private val t: Instant) : Reloj {
    override fun ahora(): Instant = t
}

@Test
fun caduca_en_el_instante_exacto() {
    val limite = Instant.parse("2026-01-01T00:00:00Z")
    val s = Suscripcion(RelojFijo(limite))
    assertFalse(s.caducada(limite))       // determinista, sin esperas ni relojes reales
}

Fíjate en lo que ha desaparecido de la prueba: no hay preparación previa, no hay limpieza posterior, no hay nada que otra prueba pueda ensuciar y no hay ninguna razón para no ejecutarla en paralelo con el resto. Ese es el indicador que conviene vigilar en una batería de pruebas: si necesitas un bloque de limpieza que reinicia el estado de un singleton entre casos, ese bloque es la factura del acoplamiento, y llegará un día en que alguien olvide actualizarlo al añadir un campo nuevo.

Cuándo es la herramienta correcta

El criterio que resume todo lo anterior cabe en una frase: un object es la herramienta correcta cuando su unicidad es una verdad sobre el dominio, y es pereza cuando es una comodidad sobre el cableado. Un comparador de cadenas es único porque no hay dos comparadores distinguibles, no porque te venga bien no pasarlo por parámetro. Un cliente HTTP, en cambio, es único solo mientras nadie necesite un segundo apuntando a otro servidor, y ese día llegará.

// Legitimo: la unicidad es parte del significado
sealed interface Resultado<out T> {
    data class Ok<T>(val valor: T) : Resultado<T>
    data object Pendiente : Resultado<Nothing>       // no hay dos pendientes distintos
}

// Pereza: la unicidad es una suposicion sobre el despliegue
object ClienteApi {
    private val http = HttpClient()
    fun trae(ruta: String): String = http.get(ruta)  // que servidor, cual timeout, como se cierra
}

La forma data object de la primera mitad merece una nota: aporta un toString legible y una igualdad estructural coherente con la identidad, y es la manera idiomática de escribir los casos sin datos de una jerarquía sellada. Ahí el singleton no es una optimización, es la representación exacta de un valor que no tiene variantes. En la segunda mitad ocurre lo contrario: cada línea comentada es una pregunta que el diseño impide formular, y ninguna de ellas se responde añadiendo más miembros al objeto.