Public get private set en Kotlin: trampas y soluciones

Public get, private set en Kotlin: cómo no pisar el rastrillo (y qué hacer si ya lo pisaste)

¡Hola, colega! Si alguna vez has buscado en Google "Kotlin public get private set var", no estás solo. Esta consulta es un verdadero éxito en Stack Overflow, y miles de desarrolladores (incluyéndome a mí en su momento) se golpearon la cabeza contra el teclado tratando de entender por qué su código no funcionaba.

¿Parece sencillo, verdad? Quiero que la propiedad sea accesible para todos (public get), pero que solo la clase pueda modificarla (private set). En Java era rutina: declarabas un campo private, escribías un getter y un setter, y hacías el setter privado. En Kotlin todo debería ser más simple, pero...

Spoiler: la sintaxis existe, pero no siempre funciona como esperas. En este artículo, analizaremos los principales errores que cometen incluso los desarrolladores experimentados y mostraremos cómo evitarlos. ¡Allá vamos!

Anatomía de una propiedad: var, val, get y set

Para empezar, un repaso rápido. En Kotlin, las propiedades no son solo campos. Son elementos completos que pueden contener getters y setters. Esta es la estructura básica:

var nombre_propiedad: Tipo = valor_por_defecto\n    get() = field\n    set(value) { field = value }

Si usas var, Kotlin genera automáticamente un getter y un setter. Pero puedes sobrescribir su comportamiento. Y también puedes cambiar su visibilidad (modificadores de visibilidad: public, private, internal, protected).

Y aquí es donde se pone interesante. Para hacer el getter público y el setter privado, debes escribir:

var name: String = "default"\n    private set

¿Eso es todo? Casi. Pero hay matices que rompen este mecanismo.

Error n.º 1: Olvidar el constructor

El problema más común es intentar declarar public get private set var en el constructor de la clase. Por ejemplo:

// ❌ Error: no se puede hacer así\nclass User(public get private set var name: String)

Kotlin mostrará un error de compilación. ¿Por qué? Porque los parámetros del constructor no son propiedades. Son solo parámetros. Si quieres que una propiedad tenga la visibilidad del setter modificada, debes declararla en el cuerpo de la clase.

Cómo hacerlo correctamente:

class User(name: String) {\n    var name: String = name\n        private set\n}

O, si usas un data class, tendrás que ingeniártelas:

data class User(private val _name: String) {\n    var name: String = _name\n        private set\n}

Sí, un data class no permite cambiar la visibilidad del setter directamente para las propiedades del constructor primario. Tendrás que usar un backing field.

Error n.º 2: Confusión con el backing field

El backing field es un campo oculto que Kotlin genera automáticamente para una propiedad si usas field en el getter o setter. Pero si sobrescribes el getter o setter sin hacer referencia a field, el backing field no se crea.

Ejemplo del problema:

var counter: Int = 0\n    private set\n    get() = field * 2 // ❌ Error: field no está definido

No, esto no es un error de compilación. Pero si escribes:

var counter: Int = 0\n    private set\n    get() = 42 // todo bien, pero field no se usa

En este caso, el backing field no se creará. Y si intentas acceder a field en el setter, obtendrás un error. La buena noticia: si usas private set, el backing field casi siempre se crea automáticamente, porque el setter por defecto usa field. Pero si sobrescribes el setter sin field, prepárate para sorpresas.

Consejo: usa siempre explícitamente field en el getter y setter si quieres trabajar con el backing field. Y recuerda: si una propiedad no tiene backing fie