Propiedades en interfaces: declarar la forma sin decidir el almacén

Casi todo el mundo llega a Kotlin arrastrando la ecuación de Java entre propiedad y campo, y esa ecuación es exactamente lo que impide entender por qué una interfaz puede declarar val nombre: String sin guardar nada. En Kotlin la propiedad es un concepto del lenguaje que se materializa en accesores; el campo de respaldo es un detalle de implementación que el compilador añade solo cuando hace falta. Una interfaz declara la forma observable del tipo —qué se puede leer, qué se puede escribir— y delega en cada implementación la decisión de dónde vive realmente ese valor: en un campo, en un cálculo, en una consulta a otro objeto o en ningún sitio. Separar contrato de almacén es lo que permite que la misma interfaz la cumpla una clase de datos, un adaptador sobre una base de datos y un doble de prueba.

Una propiedad es un par de accesores

Cuando declaras una propiedad en una interfaz no estás reservando memoria: estás exigiendo métodos. Un val se traduce en un getter abstracto; un var, en un getter y un setter abstractos. Todo lo demás es idéntico a declarar funciones.

interface Sesion {
    val id: String            // exige un getter
    var expiraEn: Long        // exige getter y setter

    val activa: Boolean       // implementada: se deriva de las anteriores
        get() = expiraEn > System.currentTimeMillis()
}

activa tiene cuerpo y sigue sin tener estado, porque su getter no lee ningún campo propio: lee otro miembro del contrato. Ese es el único tipo de propiedad implementable en una interfaz, y de nuevo aparece el patrón del nivel: la interfaz escribe el cálculo y deja abiertos los datos que lo alimentan.

Lo que no cabe es igual de instructivo. No puedes escribir un inicializador —val id: String = "x" no compila—, no puedes usar el identificador field dentro de un accesor porque no hay campo al que referirse, y no puedes delegar la propiedad con by, porque el delegado es un objeto que tendría que residir en algún sitio y ese sitio sería, otra vez, un campo por instancia.

Dónde vive el valor

La clase que implementa tiene cuatro caminos, y elegir entre ellos es una decisión de diseño real, no una formalidad sintáctica.

// 1. Campo generado por el constructor primario
class SesionMemoria(override val id: String) : Sesion {
    override var expiraEn: Long = 0L                    // 2. campo en el cuerpo
}

// 3. Cálculo puro: ningún campo
class SesionDerivada(private val token: Token) : Sesion {
    override val id: String get() = token.subject
    override var expiraEn: Long
        get() = token.exp
        set(valor) { token.exp = valor }                // 4. delegación manual a otro objeto
}

SesionMemoria guarda; SesionDerivada no guarda absolutamente nada y sin embargo cumple el mismo contrato con idéntica corrección. Desde fuera son indistinguibles, y esa indistinguibilidad es el objetivo entero del ejercicio.

Elegir entre las cuatro no es indiferente aunque el tipo sea el mismo. El campo cuesta memoria y puede quedar obsoleto si la fuente de verdad cambia por otro camino; el cálculo nunca miente pero se paga en cada lectura; la consulta a un colaborador introduce una dependencia y, con ella, la posibilidad de que leer una propiedad lance una excepción. Ninguna de esas tres características aparece en la firma, y por eso la elección pertenece a la clase: es precisamente el tipo de decisión que una interfaz no debe imponer.

Hay además una asimetría que conviene tener presente: una clase puede ampliar un val de la interfaz convirtiéndolo en var, pero nunca al revés. La razón es de subtipado puro: quien pidió poder leer sigue pudiendo leer si además se puede escribir, mientras que quien pidió poder escribir se quedaría sin la mitad del contrato si le entregas algo de solo lectura.

flowchart TD
P[Propiedad declarada en la interfaz] --> G[Getter abstracto]
P --> S[Setter abstracto solo si es var]
G --> A[Campo del constructor]
G --> B[Campo del cuerpo]
G --> C[Calculo sin campo]
G --> D[Lectura de otro objeto]

Lo que cuesta no tener campo

Una propiedad implementada en la interfaz se recalcula en cada lectura. No hay memoización posible ahí dentro, porque memoizar es guardar, y guardar es tener estado. Si el cálculo recorre una colección o toca la red, has escrito una llamada cara con aspecto de acceso a atributo, y quien la use en un bucle no tendrá ninguna pista sintáctica de lo que está pagando.

interface Informe {
    val lineas: List<String>
    val resumen: String                       // se recorre entero en cada lectura
        get() = lineas.joinToString(limit = 3)
}

class InformeCacheado(override val lineas: List<String>) : Informe {
    override val resumen: String by lazy { calcular() }      // el caché vive en la clase
    private fun calcular(): String = lineas.joinToString(limit = 3)
}

El patrón es el que conviene recordar: la interfaz define qué significa el resumen, y la clase decide cuántas veces se paga. La delegación con by lazy es legal aquí porque el delegado ya vive en una clase con campos.

La segunda trampa es de orden de inicialización. Si un accesor implementado en la interfaz lee una propiedad abstracta que la clase satisface con un campo inicializado en el cuerpo, y algo invoca ese accesor durante la construcción, leerás el valor por defecto del campo en lugar del valor previsto. Es el mismo problema de siempre con los miembros virtuales llamados desde constructores, con el agravante de que aquí la llamada tiene aspecto de simple lectura de dato.

interface Etiquetado {
    val nombre: String
    val etiqueta: String get() = nombre.uppercase()
}

class Producto : Etiquetado {
    // Se ejecuta antes de que nombre tenga valor: falla o miente.
    val cabecera = etiqueta
    override val nombre: String = "teclado"
}

La regla que evita el problema es la de siempre, pero conviene enunciarla en los términos de este nivel: durante la construcción de un objeto, todo miembro heredado —de una superclase o de una interfaz— puede estar viendo una versión a medio construir de ti mismo. Si necesitas ese valor al construir, calcúlalo tú explícitamente en vez de pedírselo a un accesor heredado.

Cuando dos interfaces piden lo mismo

Las propiedades participan de las mismas reglas de conflicto que las funciones, porque en el fondo son funciones. Si dos interfaces declaran la misma propiedad y al menos dos aportan implementación, la clase tiene que decidir con un override explícito, y puede apoyarse en super cualificado dentro del accesor.

interface ConNombreCorto { val nombre: String get() = "corto" }
interface ConNombreLargo { val nombre: String get() = "largo y descriptivo" }

class Elemento : ConNombreCorto, ConNombreLargo {
    override val nombre: String
        get() = super<ConNombreLargo>.nombre
}

El caso más interesante es el que no da error: dos interfaces que declaran la misma propiedad de forma abstracta y con el mismo tipo. Ahí no hay conflicto, hay unificación: una sola implementación satisface ambos contratos, y la clase acaba cumpliendo dos interfaces con un único campo. Es la razón por la que conviene que las propiedades de un contrato se llamen como el concepto del dominio y no como el papel que juegan en esa interfaz concreta; los nombres bien elegidos hacen que las capacidades encajen sin fricción, y los mal elegidos obligan a escribir accesores puente que no aportan nada.