Réponse.

Le mot-clé override en Kotlin est nécessaire pour désigner explicitement la redéfinition des méthodes et propriétés de la superclasse ou d'une interface.

Historique de la question

En Java, il est possible de redéfinir des méthodes de la superclasse sans mot-clé, ce qui peut parfois entraîner des erreurs ou des fautes de frappe. En Kotlin, selon le principe de sécurité, il est impératif de spécifier override pour toutes les redéfinitions et open pour le membre lui-même de la superclasse.

Problème

Le risque de masquer accidentellement les méthodes de la classe de base (accidental overriding) et la nécessité d'une gestion explicite des membres hérités. De plus, les méthodes redéfinies doivent être marquées comme open, sinon elles ne peuvent pas être redéfinies sans erreur de compilation.

Solution

Utiliser le mot-clé override avec les méthodes et propriétés de la superclasse ou de l'interface, préalablement marquées comme open, abstract ou déjà override.

Exemple de code :

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

Caractéristiques clés :

Sans le mot-clé override, il est impossible de redéfinir la méthode - il y aura une erreur de compilation ;
Par défaut, les méthodes en Kotlin sont marquées final, on ne peut redéfinir que ce qui est explicitement marqué comme open ;
Le mot-clé override supporte l'héritage multiple à travers les interfaces et les classes.

Questions pièges.

Peut-on redéfinir une propriété ou une méthode si cela n'est pas marqué comme open/abstract/override ?

Non, seuls les membres explicitement marqués open/abstract/override peuvent être redéfinis dans une sous-classe.

Le mot-clé override est-il obligatoire lors de l'implémentation d'une méthode d'interface ?

Oui, toujours, même si c'est le premier niveau d'implémentation, override est obligatoire - c'est la syntaxe de Kotlin pour l'uniformité.

Un méthode marquée comme override peut-elle être redéfinie ensuite ?

Oui, si la méthode n'est pas marquée comme final (par défaut, override hérite de open), elle peut également être redéfinie plus loin dans la hiérarchie.

Erreurs typiques et anti-modèles

Ne pas marquer open pour la méthode de base - impossible de la redéfinir, le compilateur renvoie une erreur ;
Définition incorrecte de l'intention : une erreur accidentelle dans la signature entraîne l'exécution de la mauvaise méthode ;
Tentative de redéfinir une méthode finale - impossible, erreur de compilation.

Exemples de la vie réelle

Cas négatif

Le développeur oublie de marquer open pour la classe de base :

class Cat {
    fun meow() = "meow"
}
class Tiger: Cat() {
    override fun meow() = "ROAR" // erreur de compilation
}

Avantages :

Implémentation de classe très simple.

Inconvénients :

Impossible de redéfinir le comportement, se heurte à une erreur override.

Cas positif

Définition correcte de la classe et de l'intention d'héritage :

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