Herencia: final por defecto, open y override

Kotlin invirtió el valor por defecto más caro de Java. Allí, toda clase es heredable y todo método es sobrescribible salvo que escribas final, de modo que quien no piensa en herencia acaba publicando una sin saberlo. Aquí ocurre lo contrario: nada se puede extender hasta que lo declares open, y esa inversión no es una preferencia de estilo sino la aplicación literal de un consejo que la comunidad de Java lleva repitiendo desde 2001. Diseña y documenta para la herencia, o prohíbela. Kotlin eligió que prohibirla fuera lo que pasa cuando no haces nada.

Final por defecto

Una clase de Kotlin no se puede heredar, y un miembro no se puede sobrescribir, mientras no lo digas explícitamente:

class Repositorio                    // final: nadie puede heredar de aqui
// class Cache : Repositorio()       // error: Repositorio es final

open class Servicio {                // ahora si es heredable
    fun cerrar() {}                  // pero este miembro sigue siendo final
    open fun ejecutar() {}           // este si se puede sobrescribir
}

Fíjate en que open en la clase y open en el miembro son decisiones separadas. Abrir la clase permite extenderla; no dice nada sobre qué métodos puede tocar quien extienda. Esa separación te deja publicar una clase heredable cuyo esqueleto de comportamiento sigue siendo tuyo, exponiendo como puntos de extensión solo los que has pensado y documentado.

La regla tiene tres excepciones que conviene tener claras. Los miembros de una interfaz son abiertos siempre, porque una interfaz existe precisamente para implementarse. Los miembros marcados abstract son abiertos por definición, y la clase que los contiene tiene que ser abstract. Y un miembro que ya es override queda abierto de nuevo, salvo que lo cierres a mano.

open, override y la cadena que se reabre

override no es opcional ni decorativo: es obligatorio, y sin él el compilador rechaza el código. Esto elimina de golpe dos errores clásicos de Java, el de creer que sobrescribes cuando en realidad declaras un método nuevo por una firma mal escrita, y el de sobrescribir por accidente algo que la clase base añadió en una versión posterior.

open class Figura {
    open val lados: Int = 0
    open fun dibujar() = println("figura")
}

open class Poligono : Figura() {
    override val lados: Int = 3
    final override fun dibujar() = println("poligono")  // se cierra aqui
}

class Triangulo : Poligono() {
    // override fun dibujar() {}   // error: dibujar es final en Poligono
}

El detalle que casi nadie recuerda es el del párrafo anterior: override implica open. Si sobrescribes un método en un nivel intermedio de la jerarquía, cualquier subclase más abajo podrá volver a sobrescribirlo, aunque tú creyeras haber puesto el punto final. final override es la forma de cerrar la cadena, y en clases intermedias suele ser lo que de verdad querías.

Las propiedades siguen la misma mecánica con una asimetría importante: puedes sobrescribir un val con un var, porque añades una capacidad, pero no un var con un val, porque quitarías el setter que el contrato del padre ya prometía. También puedes sobrescribir una propiedad con campo por una calculada, y viceversa, ya que —como viste en la lección anterior— desde fuera solo hay accesores.

La razón de diseño: la clase base frágil

El motivo real de cerrar por defecto tiene nombre propio: el problema de la clase base frágil. Ocurre cuando una clase padre cambia su implementación interna de una forma perfectamente correcta y, aun así, rompe subclases que ni siquiera conoce.

open class ListaContadora : ArrayList<String>() {
    var añadidos = 0
        private set

    override fun add(element: String): Boolean {
        añadidos++
        return super.add(element)
    }

    override fun addAll(elements: Collection<String>): Boolean {
        añadidos += elements.size
        return super.addAll(elements)   // si addAll llama a add, se cuenta dos veces
    }
}

El error no está en la subclase ni en la clase base: está en que la subclase depende de un detalle no documentado, si addAll usa o no add por dentro. Esa dependencia es invisible en las firmas, no la comprueba ningún compilador y se rompe con un cambio que el autor de la base considera interno y seguro.

flowchart TD
A[La clase base cambia su implementacion interna] --> B[Las firmas publicas siguen identicas]
B --> C[Las subclases compilan sin ningun aviso]
C --> D[El comportamiento cambia en tiempo de ejecucion]
D --> E[Cerrar por defecto elimina la mayoria de estos caminos]
style A fill:#f38ba8,color:#11111b
style D fill:#f9e2af,color:#11111b
style E fill:#a6e3a1,color:#11111b

Al marcar open estás firmando algo más que un permiso: te comprometes a que las llamadas internas entre tus propios métodos formen parte del contrato, y por tanto a no cambiarlas sin considerarlo una ruptura. Cerrar por defecto convierte ese compromiso en algo que se contrae a propósito y no por omisión.

La alternativa que Kotlin pone a la misma distancia sintáctica es la delegación. Con by, un tipo implementa una interfaz reenviando automáticamente todas sus llamadas a otro objeto, y lo que antes exigía heredar se resuelve envolviendo:

interface Almacen {
    fun guardar(clave: String, valor: String)
    fun leer(clave: String): String?
}

class AlmacenMemoria : Almacen {
    private val mapa = mutableMapOf<String, String>()
    override fun guardar(clave: String, valor: String) { mapa[clave] = valor }
    override fun leer(clave: String) = mapa[clave]
}

class AlmacenContado(private val base: Almacen) : Almacen by base {
    var escrituras = 0
        private set

    override fun guardar(clave: String, valor: String) {
        escrituras++
        base.guardar(clave, valor)      // llamada explicita, sin contrato oculto
    }
}

Compara esta versión con la de la lista contadora. Aquí no existe la pregunta de si un método llama a otro por dentro, porque base es un objeto distinto al que solo se accede por su interfaz. El conteo no puede duplicarse, el cambio de implementación de AlmacenMemoria no puede alterar el resultado y todo lo que ambos tipos comparten está escrito en la interfaz. La herencia resolvía el mismo problema con menos texto y con un acoplamiento que nadie declaró.