Respuesta

Por defecto, todas las clases, métodos y propiedades en Kotlin son finales (final). Esto significa que no se pueden heredar o sobreescribir a menos que se indique explícitamente el modificador open.

La palabra clave open permite la herencia de la clase o la sobreescritura de un método. Esta es una diferencia fundamental con Java, donde las clases son abiertas para la herencia por defecto.

Ejemplo:

open class Animal {
    open fun sayHello() {
        println("¡Hola desde Animal!")
    }
}

class Dog : Animal() {
    override fun sayHello() {
        println("¡Guau!")
    }
}

• Si se quita open de la clase Animal, el intento de herencia generará un error de compilación.
• override es obligatorio para los métodos/propiedades que desea sobreescribir.
• Las interfaces se implementan a través de la palabra clave interface y no requieren open.

Pregunta capciosa

¿En Kotlin se puede heredar cualquier clase de la misma manera que en Java?

Respuesta: No, solo las clases marcadas como open (o abstract). Las clases normales son finales y no se pueden heredar. Esto se hace para aumentar la seguridad y previsibilidad del código.

Ejemplo de código incorrecto:

class Animal
class Dog : Animal() // Error de compilación: "Animal" es final

Ejemplos de errores reales debido a la falta de conocimiento de las sutilezas del tema

---

Historia

En un proyecto para la plataforma Android, un desarrollador novato intentó heredar un componente personalizado de una clase View personalizada, olvidando agregar open. La compilación falló, la razón no era obvia y los plazos se retrasaron. El problema se descubrió solo después de leer detenidamente el mensaje del compilador.

---

Historia

Al desarrollar un SDK, la especificación requería una clase base extensible, pero fue declarada sin open. Después de entregarla a los clientes, se descubrió que la biblioteca no se podía extender sin cambios en el código fuente. Fue necesario lanzar una actualización.

---

Historia

En uno de los proyectos, un código Java antiguo fue migrado a Kotlin, olvidando el cierre de las clases por defecto. La mayoría de las pruebas unitarias que usaban mocks dejaron de compilar, lo que ralentizó el proceso de lanzamiento. Solo después de agregar open masivamente, se resolvió el problema.