lateinit y los campos de respaldo explícitos

Las cuatro lecciones anteriores giraron alrededor de una misma idea: interponer código entre el mundo y el estado. Esta lección cierra el nivel por el otro extremo, con las dos herramientas que resuelven problemas parecidos sin delegación y con coste cero en tiempo de ejecución. lateinit responde a la pregunta de qué hacer cuando el valor llega después de la construcción, y lleva desde 2016 pagando esa comodidad con un agujero en el sistema de tipos. Los campos de respaldo explícitos responden a la pregunta de cómo exponer una vista de solo lectura sobre un estado mutable, y desde Kotlin 2.4 son estables y jubilan definitivamente el patrón más repetido de todo el ecosistema.

lateinit por dentro

lateinit var es una promesa al compilador: este valor no es nulo, pero todavía no lo tengo, confía en mí y deja de exigirme una inicialización. Lo que genera es un campo que arranca en nulo y un getter con una comprobación:

class Servicio {
    lateinit var repo: Repositorio          // sin inicializador

    fun arrancar(r: Repositorio) { repo = r }

    fun usar() {
        if (::repo.isInitialized) repo.consultar()
    }
}

El getter equivale a devolver el campo si no es nulo y lanzar UninitializedPropertyAccessException en caso contrario. De ese código generado se deducen todas las restricciones sin memorizarlas: tiene que ser var, porque un val no admite asignación posterior; no admite tipos que se compilan a primitivos en la JVM, porque no existe un valor centinela nulo para un Int; no admite tipos nulos, porque el centinela ya está ocupado; no admite accesores propios ni delegación, porque el getter ya está escrito por el compilador; y no puede declararse en el constructor primario, que es justo lo que se está evitando. Para los primitivos, la stdlib ofrece Delegates.notNull, que es exactamente lo mismo pero implementado como delegado.

Para los tipos que sí se compilan a primitivos, el sustituto es un delegado de la stdlib, lo cual cierra el círculo de este nivel: la misma necesidad resuelta por dos mecanismos distintos, uno del compilador y otro de la biblioteca.

import kotlin.properties.Delegates

class Ventana {
    var ancho: Int by Delegates.notNull()   // lateinit no vale para Int en la JVM
}

La diferencia de coste es real: lateinit es un campo con una comprobación de nulo incrustada en el getter, mientras que Delegates.notNull es un objeto delegado extra por instancia con una llamada virtual en cada acceso. Cuando puedas usar lateinit, úsalo.

Es legítimo cuando un marco de trabajo con ciclo de vida es el dueño real de la inicialización y tú no puedes adelantarla: inyección de dependencias por campos, montaje de pruebas antes de cada caso, y componentes cuyo constructor lo llama la plataforma. En todos esos escenarios el valor está garantizado antes del primer uso por un contrato externo que el compilador no puede ver.

Y tiene tres límites que ninguna disciplina de equipo arregla. Primero: el compilador deja de ayudarte; una propiedad lateinit es exactamente igual de segura que una variable que tú prometiste no dejar nula. Segundo: no ofrece garantía alguna de visibilidad entre hilos, así que un hilo puede ver la propiedad todavía sin inicializar después de que otro la haya asignado. Tercero: el fallo aparece en el punto de lectura y no en el de la inicialización ausente, que suele estar en otro fichero y en otro momento. Si el valor puede darse en el constructor, lateinit es siempre la peor opción disponible.

El patrón de la propiedad duplicada

El otro problema clásico no es cuándo llega el valor sino quién puede modificarlo. Quieres guardar una colección o un flujo mutable y exponer al exterior una vista de solo lectura. Durante una década la única solución fue duplicar la propiedad:

class BuscadorViewModel {
    private val _estado = MutableStateFlow<Estado>(Estado.Inicial)
    val estado: StateFlow<Estado> get() = _estado

    private val _historial = mutableListOf<String>()
    val historial: List<String> get() = _historial

    fun buscar(q: String) {
        _historial.add(q)
        _estado.value = Estado.Cargando
    }
}

El precio no es la verbosidad, que sería lo de menos. El precio es que el mismo concepto tiene dos nombres y que mantener la relación entre ellos queda en manos de la convención: nada impide exponer el mutable por error, nada impide que un método interno use el nombre público y se quede sin poder mutar, nada avisa si alguien cambia el tipo de uno y no del otro, y toda la disciplina descansa en un guion bajo que ningún compilador comprueba. En bases de código grandes ese patrón aparece cientos de veces y es una fuente constante de revisiones de código dedicadas a algo que debería ser estructural.

Campos de respaldo explícitos

Kotlin 2.4 estabiliza los explicit backing fields: una propiedad puede declarar su campo de respaldo con un tipo distinto del que expone.

class BuscadorViewModel {
    val estado: StateFlow<Estado>
        field = MutableStateFlow(Estado.Inicial)

    val historial: List<String>
        field = mutableListOf<String>()

    fun buscar(q: String) {
        historial.add(q)                 // dentro de la clase es MutableList
        estado.value = Estado.Cargando   // dentro de la clase es MutableStateFlow
    }
}

Un solo nombre, dos vistas. Dentro de la clase, estado es el MutableStateFlow y el compilador lo sabe; desde fuera, estado es un StateFlow y no hay forma de escribirlo. La regla que lo gobierna es de subtipado y se recuerda sola: con el getter por defecto, el tipo del campo debe ser subtipo del tipo de la propiedad. La regla simétrica para el setter por defecto exige lo contrario, de modo que un var con ambos accesores por defecto obligaría a que los dos tipos coincidieran; por eso esta característica brilla en propiedades de solo lectura y en las que sí definen un setter propio.

Ese segundo caso es el que suele pasarse por alto y resuelve el problema de la copia defensiva al asignar:

class Documento {
    var etiquetas: Set<String>
        field = mutableSetOf<String>()
        set(nuevas) {
            field.clear()
            field.addAll(nuevas)     // dentro del setter, field es el MutableSet
        }

    fun etiquetar(t: String) {
        etiquetas.add(t)             // dentro de la clase, la vista es mutable
    }
}

Desde fuera se asigna un Set cualquiera y la clase conserva su colección; nadie retiene una referencia al conjunto interno y nadie puede mutarlo por la puerta de atrás. Escribir eso con el patrón antiguo exigía dos propiedades, un setter con nombre distinto y una convención más que recordar.

flowchart TD
A[Necesito un valor en una propiedad] --> B[Puedo pasarlo por el constructor]
B -->|si| C[Parametro del constructor y val normal]
B -->|no| D[Se calcula una vez y es puro]
D -->|si| E[by lazy]
D -->|no| F[Lo inyecta un framework externo]
F -->|si| G[lateinit var o Delegates notNull]
F -->|no| H[Expongo solo lectura sobre algo mutable]
H -->|si| I[Campo de respaldo explicito]
style I fill:#a6e3a1,color:#11111b
style G fill:#f9e2af,color:#11111b

Lo que no cambian conviene decirlo con la misma claridad. No hay copia defensiva: el objeto expuesto sigue siendo el mismo, y quien haga una conversión de tipo desde fuera alcanza el mutable, exactamente igual que con el patrón antiguo. Tampoco añaden seguridad entre hilos ni sustituyen a lateinit: son herramientas ortogonales que resuelven problemas distintos. Y no ahorran memoria, porque el patrón antiguo también tenía un único campo. Lo que eliminan es el segundo nombre, y con él una clase entera de errores de mantenimiento.

Cómo elegir