Interfaces con implementación por defecto: cuerpo sí, estado nunca

Una interfaz de Kotlin no es la interfaz de Java 6 que solo declaraba firmas, ni es una clase abstracta a la que le hubieran quitado el constructor. Es un punto intermedio deliberado: puede transportar código y no puede transportar nada que ocupe memoria en la instancia. Esa asimetría es el corazón del diseño. Puedes heredar de tantas interfaces como quieras precisamente porque ninguna de ellas trae consigo un campo susceptible de duplicarse, de inicializarse dos veces o de quedar en un orden ambiguo. Todo lo interesante de este nivel se apoya en esa regla, así que conviene entenderla no como una prohibición que hay que sortear sino como el contrato que hace posible componer comportamiento sin heredar de nadie.

Cuerpo sí, campo no

Dentro de una interfaz caben cuatro cosas: miembros abstractos, miembros con implementación, propiedades sin respaldo y funciones privadas de apoyo. No caben ni un constructor, ni un bloque init, ni el identificador field que da acceso al campo de respaldo dentro de un accesor. Esa lista negativa es toda la definición de no tener estado.

interface Auditor {
    val origen: String                        // abstracta: declara un getter

    fun registrar(evento: String)             // abstracta: sin cuerpo

    fun registrarConSello(evento: String) {   // con implementación
        registrar(sello() + " " + evento)
    }

    private fun sello(): String = "[" + origen + "]"   // auxiliar, no visible fuera
}

Fíjate en lo que ocurre en registrarConSello: el cuerpo llama a registrar, que es abstracto, y a origen, que también lo es. Una interfaz con implementación no resuelve el problema completo, sino que compone lo que aún no existe. Escribe el algoritmo y deja agujeros tipados que alguien tendrá que rellenar. Ese es el patrón de método plantilla, salvo que aquí no hay superclase que reservar.

Todos los miembros de una interfaz son implícitamente public y open; no puedes marcarlos final porque una interfaz no tiene autoridad para cerrar nada: no sabe quién la implementará ni cuántas otras interfaces convivirán con ella en la misma clase. Las funciones private con cuerpo sí están permitidas y son el sitio correcto para la lógica auxiliar que no forma parte del contrato.

Merece la pena insistir en el matiz del método plantilla, porque es el uso más productivo de esta capacidad y el que más se confunde con la herencia. Cuando una interfaz implementa una operación en términos de sus miembros abstractos, no está compartiendo código por comodidad: está fijando un algoritmo y publicando los puntos exactos por los que se puede variar. Quien implementa la interfaz no elige cómo se compone el resultado, elige qué piezas alimentan la composición. Esa es una relación mucho más estrecha y mucho más honesta que la de una superclase abierta, porque el conjunto de puntos de variación está declarado en el propio tipo en vez de esconderse en el orden de las llamadas internas.

Del cuerpo al bytecode

En la JVM, una interfaz solo puede declarar campos static final, de modo que el estado sobra por construcción. Lo que no era obvio es dónde poner el cuerpo. Durante años Kotlin no usó los métodos default de Java 8: compilaba el cuerpo a un método estático dentro de una clase anidada generada, DefaultImpls, y en cada clase implementadora emitía un método puente que delegaba en ella.

class AuditorConsola(override val origen: String) : Auditor {
    override fun registrar(evento: String) = println(evento)
    // El compilador añadía aquí un registrarConSello que llamaba a
    // Auditor.DefaultImpls.registrarConSello(this, evento)
}

Esa estrategia tenía una consecuencia muy concreta y muy cara: como el puente se copiaba en cada implementación en el momento de compilarla, añadir un método con cuerpo a una interfaz publicada no bastaba para que las clases ya compiladas contra ella lo tuvieran. Funcionaba al recompilar y fallaba en el binario ya distribuido.

flowchart LR
I[Interfaz con cuerpo] --> D[Metodo default real en la interfaz]
I --> C[Clase anidada DefaultImpls]
D --> N[Clases compiladas con el modo actual]
C --> V[Binarios antiguos que esperan el puente]

Después llegó el modificador experimental que emitía métodos default de verdad, y con Kotlin 2.2 esa opción se estabilizó como -jvm-default con el modo permisivo por defecto: la interfaz publica métodos default reales y conserva DefaultImpls para no romper a quien compiló contra la versión anterior. Existe además un modo que suprime esa clase de compatibilidad cuando controlas todo el grafo de dependencias y quieres el bytecode limpio.

Nada de esto existe fuera de la JVM. En Kotlin/Native y en Kotlin/JS el compilador tiene libertad para representar la interfaz como quiera, y el modelo que debes tener en la cabeza es el semántico: un cuerpo en la interfaz es un método virtual con implementación heredable. La discusión de DefaultImpls importa cuando publicas una librería con destino JVM y te preocupa la compatibilidad binaria.

Cuando dos interfaces dicen lo mismo

Si una clase hereda dos implementaciones distintas de la misma firma, el compilador no elige por ti: exige un override explícito. Y aquí Kotlin es más estricto que Java, porque también lo exige cuando una interfaz declara el miembro abstracto y la otra lo implementa. Java aplicaría la regla de que lo concreto gana; Kotlin te obliga a declarar tu intención.

interface Persistente {
    fun guardar() { println("persistiendo") }
    fun cerrar()
}

interface Cacheable {
    fun guardar() { println("cacheando") }
    fun cerrar() { println("cache limpiada") }
}

class Documento : Persistente, Cacheable {
    override fun guardar() {
        super<Persistente>.guardar()
        super<Cacheable>.guardar()
    }
    override fun cerrar() = super<Cacheable>.cerrar()
}

La sintaxis super<Persistente>.guardar() es la única forma de nombrar una implementación heredada concreta cuando hay ambigüedad, y solo funciona para supertipos directos. No puedes saltarte un nivel ni alcanzar la implementación de una interfaz que herede otra interfaz intermedia. Esa restricción es deliberada: el envío dinámico sigue siendo el mecanismo normal, y super cualificado es una fuga controlada que el lenguaje limita al vecindario inmediato.

Observa también que el override obligatorio no te obliga a elegir: puedes llamar a las dos implementaciones, a ninguna, o escribir algo completamente distinto. El compilador no arbitra el conflicto, solo se niega a resolverlo en tu lugar. Esa negativa es exactamente lo que distingue la herencia múltiple de comportamiento —resoluble, local y explícita— de la herencia múltiple de estado, que no admite una resolución tan barata.

Interfaz con cuerpo o clase abstracta

La pregunta natural al final de todo esto es qué queda entonces para la clase abstracta, y la respuesta es limpia: le queda el estado y le queda el constructor. Si lo que compartes entre las implementaciones es un algoritmo, la interfaz lo hace igual de bien y además deja libre la ranura de herencia para otra cosa. Si lo que compartes son campos, un invariante que hay que establecer al construir o una inicialización con orden, la clase abstracta es el único sitio donde eso se puede expresar.

// Algoritmo compartido: interfaz. Se puede combinar con otras.
interface Reintentable {
    val intentos: Int
    fun ejecutar(): Boolean
    fun ejecutarConReintentos(): Boolean =
        (1..intentos).any { ejecutar() }
}

// Estado compartido e invariante: clase abstracta.
abstract class Conexion(protected val destino: String) {
    init { require(destino.isNotBlank()) }
    abstract fun abrir()
}

En la práctica la combinación más frecuente y más sana es tener las dos cosas: una interfaz que define el contrato y lo que se pueda derivar de él, y opcionalmente una clase abstracta de conveniencia que lo implemente parcialmente con estado para quien quiera heredar. Quien no pueda heredar —porque ya tiene superclase, porque no controla el tipo, porque prefiere componer— sigue teniendo la interfaz disponible.