Los delegados de la stdlib: observable, vetoable, mapas y alias

Antes de escribir tu propio delegado conviene agotar los cuatro que la biblioteca estándar ya te regala, porque cubren una fracción sorprendente de los casos reales y porque cada uno enseña una idea distinta sobre qué se puede hacer en el punto de acceso. observable demuestra que un set puede notificar; vetoable, que puede negarse; la delegación en un Map demuestra que el estado no tiene por qué vivir en campos; y la delegación en otra propiedad demuestra que el nombre de una propiedad y su almacenamiento son cosas separables. Los cuatro tienen letra pequeña, y toda ella se deduce de mirar el setValue que ejecutan.

observable y vetoable: el mismo motor, dos ganchos

Ambos salen de la misma clase abstracta, y leerla desmonta cualquier misterio:

abstract class ObservableProperty<V>(initialValue: V) : ReadWriteProperty<Any?, V> {
    private var value = initialValue

    protected open fun beforeChange(prop: KProperty<*>, viejo: V, nuevo: V): Boolean = true
    protected open fun afterChange(prop: KProperty<*>, viejo: V, nuevo: V) {}

    override fun getValue(thisRef: Any?, prop: KProperty<*>): V = value

    override fun setValue(thisRef: Any?, prop: KProperty<*>, value: V) {
        val viejo = this.value
        if (!beforeChange(prop, viejo, value)) return   // veto silencioso
        this.value = value
        afterChange(prop, viejo, value)                 // notificacion posterior
    }
}

Delegates.observable implementa afterChange; Delegates.vetoable, beforeChange.

import kotlin.properties.Delegates

class Usuario {
    var nombre: String by Delegates.observable("anonimo") { prop, viejo, nuevo ->
        println("${prop.name} paso de $viejo a $nuevo")
    }

    var edad: Int by Delegates.vetoable(0) { _, _, nuevo -> nuevo in 0..130 }
}

Cuatro detalles que se pagan caros si se ignoran. Uno: observable no compara el valor viejo con el nuevo, así que asignar el mismo valor dispara la notificación igualmente; si tu observador redibuja una pantalla, acabas de crear trabajo inútil. Dos: la notificación llega después de la escritura, de modo que leer la propiedad dentro del callback devuelve el valor nuevo. Tres: un veto rechazado es silencioso, no lanza nada, y desde fuera parece que la asignación simplemente no ocurrió. Cuatro: ni el valor inicial pasa por beforeChange, ni la secuencia leer-modificar-notificar es atómica, así que en concurrencia dos hilos pueden notificar transiciones incoherentes.

flowchart TD
A[Asignacion a la propiedad] --> B[setValue del delegado]
B --> C[beforeChange con viejo y nuevo]
C -->|devuelve false| D[Se descarta sin aviso]
C -->|devuelve true| E[Escribe el campo interno]
E --> F[afterChange notifica a quien escuche]
style D fill:#f38ba8,color:#11111b
style F fill:#a6e3a1,color:#11111b

Cuando necesites las dos mitades a la vez —validar y notificar— no encadenes delegados: extiende ObservableProperty y sobrescribe ambos métodos. Es la forma soportada, evita duplicar el campo y te deja además arreglar los dos silencios de la stdlib.

class Validada<V>(
    inicial: V,
    private val regla: (V) -> Boolean,
    private val alCambiar: (V) -> Unit,
) : ObservableProperty<V>(inicial) {

    override fun beforeChange(prop: KProperty<*>, viejo: V, nuevo: V): Boolean {
        require(regla(nuevo)) { "valor invalido para ${prop.name}: $nuevo" }
        return viejo != nuevo          // ignora asignaciones que no cambian nada
    }

    override fun afterChange(prop: KProperty<*>, viejo: V, nuevo: V) = alCambiar(nuevo)
}

Ese return viejo != nuevo es el detalle que convierte el delegado en útil: rechaza sin ruido las escrituras idempotentes y solo notifica transiciones reales, mientras que la excepción convierte los valores inválidos en un fallo visible en el punto exacto de la asignación.

Delegar en un Map

Un Map no sabe nada de delegación; es la stdlib la que le añade un getValue por extensión, usando el nombre de la propiedad como clave. La versión mutable añade setValue.

class Configuracion(private val origen: MutableMap<String, Any?>) {
    var host: String by origen        // clave "host"
    var puerto: Int by origen         // clave "puerto"
}

Es un patrón excelente para envolver datos dinámicos —una respuesta JSON ya deserializada, variables de entorno, un documento de configuración— con una fachada tipada y legible. Y es un patrón pésimo para un modelo de dominio, por tres razones concretas.

La primera: la conversión al tipo declarado es una comprobación sin garantía estática, así que un tipo equivocado en el mapa no falla al construir el objeto sino en el instante en que alguien lee la propiedad, potencialmente muy lejos. La segunda: si la clave no existe, el acceso lanza NoSuchElementException, salvo que envuelvas el mapa con withDefault. La tercera, la más traicionera: al usar el nombre de la propiedad como clave, el nombre pasa a formar parte de tu formato de datos; renombrar una propiedad en una refactorización deja de ser una operación segura y se convierte en un cambio de contrato que ningún compilador va a señalar.

// sin red: NoSuchElementException al leer una clave ausente
class Estricta(origen: Map<String, Any?>) {
    val host: String by origen
}

// con red: el valor por defecto se calcula a partir de la clave
class Tolerante(origen: Map<String, Any?>) {
    private val datos = origen.withDefault { clave -> "sin $clave" }
    val host: String by datos
}

Si el nombre en disco importa, la solución no es renunciar al patrón sino recuperarlo bajo control: un provideDelegate que reciba la clave explícita, como el de la lección anterior, te devuelve la comodidad sin atar tu formato de datos al refactorizador del IDE.

Delegar en otra propiedad

Desde Kotlin 1.4 puedes poner una referencia de propiedad detrás de by. El compilador genera acceso directo, sin reflexión en tiempo de ejecución, y el resultado es un alias real.

class Api {
    var tiempoDeEspera: Int = 30

    @Deprecated("Usa tiempoDeEspera", ReplaceWith("tiempoDeEspera"))
    var timeout: Int by ::tiempoDeEspera          // alias de la misma clase
}

class Vista(private val modelo: Modelo) {
    val titulo: String by modelo::nombre          // alias de otro objeto
}

var contadorGlobal: Int = 0
val copia: Int by ::contadorGlobal                // alias de nivel superior

Sirve para tres cosas muy concretas: renombrar una propiedad pública sin romper a quien la usa, aplanar un acceso anidado que ensuciaba el código de llamada, y exponer en solo lectura algo que por debajo es mutable. La restricción es que los tipos deben coincidir, y que aliasar un var exige que el destino también sea var.