Delegación con by: reenvío generado, y el envío que nunca vuelve

Escribir un decorador a mano es una de las tareas más humillantes de la programación orientada a objetos: cuarenta métodos que no hacen nada salvo pasar la pelota, uno de los cuales hace algo interesante, y ninguna manera de que el compilador te avise si mañana la interfaz crece y olvidas uno. Kotlin resolvió esa humillación con dos caracteres en la lista de supertipos. Pero la delegación no es herencia disfrazada ni herencia mejorada: es una construcción distinta con garantías distintas, y la diferencia se paga siempre en el mismo sitio. Quien entiende qué genera el compilador y qué relación queda entre el decorador y el decorado usa by con precisión quirúrgica; quien lo trata como un atajo para heredar escribe bugs que solo aparecen cuando alguien llama al método equivocado.

Qué escribe el compilador por ti

La forma canónica declara la interfaz en la lista de supertipos y, tras by, una expresión que produce un objeto que ya la cumple.

interface Repositorio {
    fun leer(id: String): String?
    fun escribir(id: String, valor: String)
    fun borrar(id: String)
}

class RepositorioConTraza(
    private val origen: Repositorio,
    private val log: (String) -> Unit
) : Repositorio by origen {

    override fun escribir(id: String, valor: String) {
        log("escribir " + id)
        origen.escribir(id, valor)
    }
}

El compilador recorre los miembros de Repositorio, descarta los que tú has sobrescrito y genera un reenvío para cada uno de los restantes. Aquí eso significa que leer y borrar existen en la clase aunque no las hayas escrito, y que su cuerpo es una llamada al delegado. El delegado no se relee de la propiedad en cada uso: la expresión que sigue a by se evalúa una sola vez, durante la construcción, y su resultado se guarda en un campo sintético que suele aparecer en el bytecode con un nombre como $$delegate_0.

De ahí salen tres consecuencias que conviene fijar. Si la expresión delegada es una propiedad mutable, reasignarla después no cambia a quién reenvían los métodos generados. Si el delegado es también una propiedad tuya, hay dos referencias al mismo objeto: la tuya y la sintética. Y si no necesitas la tuya, puedes ahorrártela declarando el parámetro del constructor sin val y delegando directamente sobre él.

Hay una asimetría importante frente a la herencia: by solo funciona con interfaces. No puedes delegar en una clase, ni siquiera abierta, porque delegar exige un conjunto de miembros bien definido y virtualizable que solo un contrato puro garantiza. Eso empuja el diseño en una dirección concreta y saludable: para poder componer, primero hay que haber extraído la interfaz, y extraer la interfaz obliga a decidir qué forma parte del contrato y qué es implementación.

El envío que no vuelve

Aquí está el fondo del asunto. El delegado es un objeto independiente que fue construido sin saber que alguien lo iba a envolver: no tiene ninguna referencia al decorador. Cuando uno de sus propios métodos llama a otro método suyo, esa llamada se resuelve dentro de él y nunca sube al decorador.

class ListaContadora<T>(
    private val interna: MutableList<T> = mutableListOf()
) : MutableList<T> by interna {

    var altas = 0
        private set

    override fun add(element: T): Boolean {
        altas++
        return interna.add(element)
    }
}

val lista = ListaContadora<String>()
lista.add("a")                     // altas pasa a 1
lista.addAll(listOf("b", "c"))     // altas sigue siendo 1

addAll no está sobrescrito, así que se reenvía tal cual a interna.addAll, y esa implementación inserta llamando a su add, no al tuyo. El contador miente. Con herencia real esto habría funcionado, porque la subclase y la superclase son el mismo objeto y el envío virtual sube siempre al override más derivado.

Lo grave del ejemplo no es que falle, sino cómo falla: sin excepción, sin advertencia del compilador y sin ninguna pista en el tipo. El programa compila, los tests que solo usan add pasan, y el error aparece meses después en un informe donde las cifras no cuadran. Es exactamente la clase de fallo que un sistema de tipos no puede atrapar, porque no hay nada mal tipado: la delegación está haciendo con total corrección lo único que sabe hacer.

flowchart LR
C[Llamada externa] --> D[Decorador]
D --> R[Reenvio generado]
R --> O[Objeto delegado]
O --> S[Llamada interna del delegado]
S --> O
D -.no la alcanza.-> S

Merece la pena señalar el detalle simétrico: los métodos con cuerpo de la interfaz tampoco escapan a esta regla. Si el contrato trae una implementación por defecto y el delegado la ha sobrescrito, el reenvío generado llamará a la versión del delegado; si no la ha sobrescrito, llamará a la versión por defecto ejecutada sobre el delegado. En los dos casos, el receptor es el objeto de dentro. Tu decorador nunca aparece como receptor de nada que él mismo no haya declarado.

Esa flecha punteada es toda la lección. La delegación no crea una identidad compartida, crea una cadena de objetos, y la polimorfía se detiene en el primer eslabón. No es un defecto de Kotlin: es la definición de composición. Cualquier lenguaje que reenvíe en lugar de heredar tiene exactamente el mismo comportamiento, y la única forma de evitarlo es que la interfaz esté diseñada de modo que sus operaciones compuestas se apoyen en las primitivas a través del receptor externo, cosa que casi ninguna interfaz de biblioteca garantiza porque nunca lo prometió.

Decorar sin escribir métodos

Cuando la limitación anterior no aplica, la técnica es imbatible. Los casos buenos comparten un rasgo: el método que sobrescribes es una hoja del contrato, no una operación que otras invoquen internamente.

// Restringir: se expone solo lectura sobre algo mutable.
class SoloLectura<T>(fuente: List<T>) : List<T> by fuente

// Combinar dos capacidades sin una sola línea de reenvío manual.
interface Lector { fun leer(id: String): String? }
interface Escritor { fun escribir(id: String, v: String) }

class Almacen(
    lector: Lector,
    escritor: Escritor
) : Lector by lector, Escritor by escritor

La delegación múltiple es legal mientras las interfaces no compartan firmas; si las comparten, el compilador exige un override explícito igual que en el conflicto de implementaciones por defecto. Y como el conjunto de reenvíos se calcula al compilar la clase, añadir un miembro abstracto a la interfaz delegada no rompe nada: el compilador simplemente generará uno más la próxima vez.

Hay un patrón adicional que aprovecha que la expresión delegada es una expresión cualquiera y no necesariamente un parámetro: delegar en un objeto construido en el sitio. class Registro : MutableList<String> by mutableListOf() produce un tipo nominal propio que se comporta como una lista y que puede crecer con métodos suyos, sin exponer ni permitir sustituir el almacén interno. Es la forma más barata que existe en Kotlin de crear un tipo de dominio a partir de una colección sin heredar de ella.

La contrapartida de todo lo anterior es que el decorador no es sustituible por el decorado en términos de identidad. Si un marco de trabajo recibe tu envoltorio, lo registra y luego devuelve en una llamada de vuelta la referencia interna que él mismo guardó, el resto del sistema verá al objeto envuelto y tu capa desaparecerá del recorrido. Ese fallo no lo detecta ningún tipo y solo se manifiesta en ejecución, así que conviene comprobarlo la primera vez que un decorador cruza una frontera que no controlas.