Propiedades, no campos: getter, setter y field

La frase que más se repite al enseñar Kotlin es que las propiedades son campos con getter y setter automáticos. Es falsa, y la falsedad tiene consecuencias. Una propiedad no es un campo: es un par de accesores, y el campo detrás es un detalle de implementación que puede existir o no. Cuando entiendes que lo que declaras es una operación de lectura y no una casilla de memoria, tres cosas dejan de sorprenderte: que una propiedad pueda no ocupar ni un byte, que el identificador field aparezca de la nada dentro de un accesor, y que Kotlin haya decidido, deliberadamente, no ofrecerte campos públicos aunque la JVM los tenga.

Una propiedad es un par de accesores

Declarar val nombre: String no declara memoria: declara una operación de lectura llamada getNombre. Declarar var añade además una operación de escritura. El campo aparece solo si algún accesor lo necesita:

class Persona(nombre: String) {

    var nombre: String = nombre           // hay campo: el accesor por defecto lo usa
        get() = field.trim()
        set(valor) {
            require(valor.isNotBlank()) { "nombre vacio" }
            field = valor.trim()
        }
}

La regla exacta que aplica el compilador es sencilla y merece memorizarse: se genera un campo de respaldo si, y solo si, algún accesor usa el identificador field, o si al menos uno de los accesores es el que viene por defecto. Fuera de ese caso, no hay campo, y la propiedad es puro código.

field es un identificador especial que solo existe dentro del cuerpo de un getter o un setter, y su razón de ser es evitar una recursión infinita. Si dentro del getter escribieras nombre en lugar de field, estarías llamando al propio getter, que volvería a llamarse, hasta desbordar la pila. field es la única forma de decir la casilla, distinguiéndola de la operación.

flowchart LR
P[Declaracion de propiedad] --> G[Getter]
P --> S[Setter solo si es var]
G --> F[Campo de respaldo]
S --> F
F --> R[Existe solo si algun accesor usa field o es el accesor por defecto]
style P fill:#89b4fa,color:#11111b
style F fill:#f9e2af,color:#11111b
style R fill:#a6e3a1,color:#11111b

Una consecuencia práctica: el modificador de visibilidad puede aplicarse al setter por separado. private set deja la propiedad legible desde fuera y escribible solo desde dentro, que es la forma canónica de exponer estado mutable sin ceder el control de cuándo cambia.

class Contador {
    var valor: Int = 0
        private set                    // se lee fuera, se escribe solo aqui

    fun incrementar() { valor++ }
}

Esa asimetría solo existe porque la propiedad son dos operaciones y no una casilla: un campo, por definición, se lee y se escribe con la misma visibilidad. Fíjate también en que el setter puede tener visibilidad distinta pero no un tipo distinto: el parámetro del setter es siempre del tipo de la propiedad, precisamente porque ambos accesores describen el mismo concepto visto en dos direcciones.

Hay un tercer estado que merece nombre propio. Una propiedad puede declararse lateinit var para prometer al compilador que la asignarás antes de leerla, saltándote la exigencia de valor inicial sin recurrir a un tipo nulable. Es una concesión pragmática para inyección de dependencias y ciclos de vida ajenos, y su precio es que la comprobación pasa de compilación a ejecución: leerla antes de tiempo lanza una excepción con un mensaje explícito en lugar de un error del compilador.

Propiedades calculadas: cero bytes, cero sincronización

Cuando el getter deriva su resultado de otras propiedades, no hay campo y no hay memoria ocupada:

class Rectangulo(val ancho: Double, val alto: Double) {
    val area: Double get() = ancho * alto            // sin campo
    val esCuadrado: Boolean get() = ancho == alto    // sin campo
}

Compara eso con guardar area en un campo asignado en el constructor. La versión con campo cuesta ocho bytes por instancia y, sobre todo, introduce una segunda fuente de verdad: si algún día ancho pasa a ser mutable, existirá un instante en el que el área guardada ya no corresponde a las medidas. La versión calculada no puede desincronizarse porque no hay nada que sincronizar. Ese es el criterio de elección: si el valor es una función de otros datos, calcúlalo; guarda solo lo que es realmente independiente.

El coste, claro, es que el cálculo se repite en cada lectura. Cuando ese cálculo es caro y el dato no cambia, la respuesta correcta no es volver al campo asignado a mano, sino by lazy, que combina lo mejor de ambos: se calcula una vez, la primera vez que alguien lo pide, y después se sirve desde memoria.

class Documento(val texto: String) {
    val indice: Map<String, Int> by lazy {          // caro, se calcula una sola vez
        texto.split(" ").withIndex().associate { (i, palabra) -> palabra to i }
    }
}

Por qué Kotlin no tiene campos públicos

Aquí está la decisión de diseño de fondo, y no es estética. En Java, punto.x compila a un acceso directo al campo y punto.getX() compila a una llamada a método. Son instrucciones distintas del bytecode, así que el día que necesites validar la escritura o derivar el valor, cambiar el campo público por accesores rompe la compatibilidad binaria: todo el código ya compilado que dependía de ti deja de enlazar y hay que recompilarlo. Esa amenaza es la que obliga a la industria de Java a escribir getters triviales desde el primer día, por si acaso.

Kotlin corta el nudo por el otro lado: no te deja exponer campos, así que en el sitio de llamada siempre hay una invocación de accesor, aunque tú hayas escrito una asignación con aspecto de campo. La sintaxis se parece a la de un campo y la semántica es la de un método.

// Version 1 de la libreria: propiedad con campo
class Config(val ruta: String)

// Version 2: se vuelve calculada. El bytecode del llamante NO cambia
class Config(private val base: String) {
    val ruta: String get() = base.removeSuffix("/")
}

Esto es el principio de acceso uniforme de Bertrand Meyer llevado al nivel del lenguaje: quien consume un valor no debería saber si está almacenado o computado, porque esa elección es del implementador y debe poder cambiar. Kotlin lo hace cumplir por construcción en lugar de dejarlo a la disciplina.

La misma uniformidad explica un detalle de la herencia que sorprende al venir de Java: una subclase puede sobrescribir una propiedad con campo por una calculada, o al revés, porque lo que hereda es el accesor y no la casilla. La representación nunca formó parte del contrato, así que cambiarla en un descendiente no rompe nada.

Las dos escapatorias existen y son explícitas, precisamente para que se vean. @JvmField elimina los accesores y expone el campo, útil solo cuando interoperas con código Java o con una librería que reflexiona sobre campos. Y const val, para constantes de tipos primitivos y String conocidas en compilación, que se insertan literalmente en el sitio de llamada.

class Punto(@JvmField val x: Int, @JvmField val y: Int)   // campo publico real

object Limites {
    const val MAXIMO = 100        // se inserta en el bytecode del llamante
}