Respuesta.

La palabra clave override en Kotlin se utiliza para indicar explícitamente la sobreescritura de métodos y propiedades de una superclase o interfaz.

Historia del tema

En Java, se pueden sobreescribir métodos de la superclase sin la palabra clave, lo que a veces puede dar lugar a errores o errores tipográficos. En Kotlin, siguiendo el principio de seguridad, se requiere especificar override para cualquier sobreescritura y open para el propio miembro de la superclase.

Problema

El riesgo de ocultar accidentalmente métodos de la clase base (accidental overriding) y la necesidad de gestionar explícitamente los miembros heredados. Además, los métodos sobreescritos deben estar marcados como open; de lo contrario, no se pueden sobreescribir sin un error de compilación.

Solución

Usar la palabra clave override con métodos y propiedades de la superclase o interfaz, que previamente estén marcados como open, abstract o ya override.

Ejemplo de código:

open class Animal {
    open fun sound() = "???"
}
class Dog : Animal() {
    override fun sound() = "Woof!"
}

Características clave:

Sin la palabra clave override, no se puede sobreescribir el método: habrá un error de compilación;
Por defecto, se aplica final a los métodos en Kotlin, solo se puede sobreescribir aquello que esté claramente marcado como open;
La palabra clave override admite herencia múltiple a través de interfaces y clases.

Preguntas capciosas.

¿Se puede sobreescribir una propiedad o método si no está marcado como open/abstract/override?

No, solo los miembros marcados explícitamente como open/abstract/override pueden ser sobreescritos en la subclase.

¿Es obligatorio el override al implementar un método de interfaz?

Sí, siempre, incluso si es el primer nivel de implementación, el override es obligatorio: esta es la sintaxis de Kotlin para la uniformidad.

¿Puede un método marcado como override ser nuevamente sobreescrito?

Sí, si el método no está marcado como final (por defecto, el override hereda open), entonces también se puede sobreescribir más en la jerarquía.

Errores típicos y antipatrón

No colocar open en el método base: imposible sobreescribirlo, el compilador dará un error;
Definición incorrecta de la intención: un error accidental en la firma conduce a la ejecución del método incorrecto;
Intento de sobreescribir un método final: no es posible, error de compilación.

Ejemplo de la vida real

Caso negativo

Un desarrollador olvida poner open en la clase base:

class Cat {
    fun meow() = "meow"
}
class Tiger: Cat() {
    override fun meow() = "ROAR" // error de compilación
}

Ventajas:

Implementación más sencilla de la clase.

Desventajas:

No se puede sobreescribir el comportamiento, se produce un error de override.

Caso positivo

Definición correcta de la clase y la intención de herencia:

open class Cat {
    open fun meow() = "meow"
}
class Tiger: Cat() {
    override fun meow() = "ROAR"
}