Antwoord.

Het sleutelwoord override in Kotlin is nodig om expliciet aan te geven dat methoden en eigenschappen van een superklasse of interface worden overschreven.

Geschiedenis van de kwestie

In Java kunnen methoden van een superklasse worden overschreven zonder sleutelwoord, wat soms kan leiden tot fouten of typfouten. In Kotlin, volgens het principe van veiligheid, is het verplicht om override te vermelden voor enige overschrijvingen en open voor het lid zelf van de superklasse.

Probleem

Het risico van onbedoeld verbergen van methoden van de basis klasse (accidental overriding) en de noodzaak van expliciete controle over de geërfde leden. Bovendien moeten de methoden die kunnen worden overschreven, worden gemarkeerd als open, anders kan er geen overschrijving plaatsvinden zonder een compileerfout.

Oplossing

Gebruik van het sleutelwoord override met methoden en eigenschappen van de superklasse of interface, voorafgaand gemarkeerd als open, abstract of al override.

Voorbeeldcode:

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

Belangrijke kenmerken:

Zonder het sleutelwoord override kan de methode niet worden overschreven — er zal een compileerfout zijn;
Methoden zijn standaard in Kotlin final, alleen diegene die expliciet als open zijn gemarkeerd kunnen worden overschreven;
Het sleutelwoord override ondersteunt meervoudige overerving via interfaces en klassen.

Vragen met een valstrik.

Kun je een eigenschap of methode overschrijven als deze niet als open/abstract/override is gemarkeerd?

Nee, alleen leden die expliciet als open/abstract/override zijn gemarkeerd, kunnen in een subklasse worden overschreven.

Is override verplicht bij het implementeren van een methode van een interface?

Ja, altijd, zelfs als het het eerste niveau van implementatie is, override is verplicht — dat is de syntaxis van Kotlin voor consistentie.

Kan een methode die als override is gemarkeerd verder worden overschreven?

Ja, zolang de methode niet als final is gemarkeerd (standaard erft override open), kan deze ook verder worden overschreven in de hiërarchie.

Typische fouten en antipatterns

Geen open bij de basis methode zetten — kan niet worden overschreven, de compiler geeft een foutmelding;
Onjuiste definitie van de intentie: een onopzettelijke fout in de handtekening leidt tot het uitvoeren van een andere methode;
Poging om een final methode te overschrijven — onmogelijk, compilerfout.

Voorbeeld uit het leven

Negatief geval

Een ontwikkelaar vergeet open bij de basis klasse:

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

Voordelen:

Eenvoudige implementatie van de klasse.

Nadelen:

Kan het gedrag niet overschrijven, er ontstaat een override fout.

Positief geval

Juiste definitie van de klasse en de intentie van overerving:

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