Expresiones de objeto: clases anónimas con memoria

La declaración object produce una instancia única y con nombre. Su hermana, la expresión de objeto, hace lo contrario: fabrica una instancia nueva cada vez que se evalúa y, con frecuencia, ni siquiera le da un tipo con nombre. Es el sustituto directo de la clase anónima de Java, pero con dos diferencias que cambian el cálculo de diseño: puede implementar varias interfaces a la vez y puede capturar variables mutables del ámbito que la rodea. De esas dos capacidades salen tanto los usos legítimos que ninguna lambda cubre como la familia de fugas de memoria más común en aplicaciones con ciclo de vida. Aprender a decidir entre una lambda y una expresión de objeto no es una cuestión de estilo: es una pregunta sobre cuántos métodos tiene el contrato y cuánto tiempo va a vivir la referencia.

Una expresión, no una declaración

La sintaxis se parece, pero el significado es opuesto. Donde la declaración crea una instancia global y perezosa, la expresión crea una instancia local y ansiosa: su cuerpo se ejecuta en el momento en que la expresión se evalúa, y cada evaluación produce un objeto distinto con su propia identidad.

fun observador(prefijo: String): Oyente = object : Oyente, Cerrable {
    private var recibidos = 0

    override fun alRecibir(evento: Evento) {
        recibidos++
        println("$prefijo $recibidos ${evento.nombre}")
    }

    override fun cerrar() = println("$prefijo cerrado tras $recibidos")
}

Ese objeto implementa dos interfaces a la vez. Ninguna lambda puede hacerlo, y esa es ya una primera frontera dura. También puede heredar de una clase abierta y llamar a su constructor con argumentos, lo que la convierte en la única forma de sobrescribir puntualmente el comportamiento de una clase sin declarar un tipo nuevo con nombre.

El detalle que casi nadie conoce es cómo se comporta el tipo resultante cuando no declaras supertipos. Un objeto anónimo tiene un tipo anónimo real, con todos sus miembros, pero ese tipo solo es visible si la declaración que lo devuelve es local o privada. En cuanto la firma es pública o interna, el compilador ensancha el tipo al supertipo declarado y, si no hay ninguno, a Any.

private fun interno() = object { val marca = 1 }
fun publico() = object { val marca = 1 }

fun uso() {
    interno().marca   // compila: el tipo anonimo se filtra en ambito privado
    publico().marca   // error: el tipo visto es Any
}

La regla tiene una razón sólida. Un tipo anónimo no tiene nombre que escribir en un fichero de cabecera ni en la firma de una biblioteca compilada, de modo que exponerlo públicamente crearía una dependencia que nadie puede nombrar. Al restringir su filtración a lo local y lo privado, Kotlin te deja usarlo como una tupla ad hoc dentro de una función sin comprometer la superficie pública.

Conviene además fijar la diferencia de identidad, porque es la fuente de errores más silenciosa. Una declaración object evaluada dos veces devuelve el mismo objeto; una expresión evaluada dos veces devuelve dos objetos distintos que no son iguales entre sí salvo que hayas redefinido la igualdad.

object Unico
val a = Unico; val b = Unico
println(a === b)                      // true, siempre

fun nuevo() = object : Runnable { override fun run() = Unit }
println(nuevo() === nuevo())          // false, dos instancias distintas

Esto importa mucho al registrar y dar de baja oyentes: dar de baja pasando una expresión de objeto recién creada nunca elimina nada, porque el registro compara con la instancia que guardó y no con la que acabas de fabricar. Hay que conservar la referencia original en una variable.

Lo que el objeto se lleva dentro

Una expresión de objeto captura el entorno léxico donde aparece, y aquí Kotlin se separa de Java de forma sustancial: no exige que las variables capturadas sean efectivamente finales, así que puedes leerlas y también escribirlas.

fun contador(): () -> Int {
    var n = 0                       // capturada y mutada desde dentro
    return object : () -> Int {
        override fun invoke(): Int = ++n
    }
}

El mecanismo no es magia: el compilador detecta que n se captura y se muta, y la promueve a un objeto contenedor de la biblioteca interna, del estilo de Ref.IntRef para primitivos o Ref.ObjectRef para referencias. La variable deja de vivir en la pila y pasa al montículo, dentro de una celda compartida por la función y por el objeto anónimo. Eso explica dos cosas que se observan en un perfilador: la asignación extra que aparece al capturar variables mutables, y el hecho de que la mutación sea visible en ambos lados, con todas las consecuencias que eso tiene si varios hilos tocan la celda.

flowchart LR
F[Marco de la funcion contador] --> R[Celda Ref.IntRef en el monticulo]
O[Objeto anonimo creado por la expresion] --> R
O --> T[Referencia implicita al this exterior si lo hay]
T --> C[El contenedor completo queda retenido]
style R fill:#f9e2af,color:#11111b
style C fill:#f38ba8,color:#11111b

La flecha de la derecha es la que causa problemas reales. Si la expresión de objeto aparece dentro de un miembro de una clase, el objeto anónimo guarda una referencia implícita a la instancia que lo creó, porque necesita poder resolver this para llamar a sus miembros. Un oyente anónimo registrado en un bus de eventos global mantiene vivo, por esa referencia, todo el objeto que lo declaró y, transitivamente, cuanto cuelgue de él. Es el mecanismo exacto de la fuga clásica en interfaces con ciclo de vida: la pantalla se destruye, el bus sigue vivo, y el bus sostiene la pantalla entera.

class Pantalla(private val datos: ByteArray) {          // varios megabytes
    fun arranca() {
        BusGlobal.registra(object : Oyente {            // captura this de Pantalla
            override fun alRecibir(e: Evento) = pinta(e)
        })
    }

    private fun pinta(e: Evento) { /* usa datos */ }
}

Dentro de alRecibir se llama a pinta, que es un miembro de Pantalla, así que el objeto anónimo necesita el contenedor y lo retiene. Basta con que la expresión no toque nada del exterior para que el compilador no genere esa referencia; el diagnóstico útil, por tanto, es preguntarse qué del ámbito exterior se está usando de verdad dentro del cuerpo. Si la respuesta es “un par de valores”, extraerlos a variables locales antes de crear el objeto rompe el enlace con el contenedor y convierte la fuga en una retención acotada.

Dónde una lambda deja de servir

La conversión SAM permite escribir una lambda allí donde se espera una interfaz con un único método abstracto: automáticamente para interfaces de Java, y para interfaces de Kotlin solo si están declaradas como fun interface. Fuera de ese caso, la lambda no es una opción y la expresión de objeto es la respuesta.

fun interface Filtro { fun acepta(s: String): Boolean }

interface Ciclo {                      // dos metodos: no hay conversion posible
    fun alAbrir()
    fun alCerrar()
}

val f = Filtro { it.isNotEmpty() }     // lambda: un solo metodo abstracto

val c = object : Ciclo {               // obligatorio: hay que nombrar cada uno
    override fun alAbrir() = println("abierto")
    override fun alCerrar() = println("cerrado")
}

El eje del coste apunta en dirección contraria. Desde Kotlin 2.0, las lambdas destinadas a la JVM se compilan por defecto mediante invokedynamic y la fábrica de la plataforma, lo que permite que una lambda que no captura nada se resuelva a una instancia única y reutilizada, y que el enlace se retrase al primer uso. Una expresión de objeto, en cambio, asigna un objeto nuevo en cada evaluación sin excepción. En un bucle caliente esa diferencia es real y se mide.