Réponse

Par défaut, toutes les classes, méthodes et propriétés en Kotlin sont finales (final). Cela signifie qu'elles ne peuvent pas être héritées ou redéfinies, sauf si le modificateur open est spécifiquement mentionné.

Le mot-clé open permet l'héritage d'une classe ou la redéfinition d'une méthode. C'est une distinction fondamentale par rapport à Java, où les classes sont par défaut ouvertes à l'héritage.

Exemple :

open class Animal {
    open fun sayHello() {
        println("Bonjour de l'Animal !")
    }
}

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

• Si open est retiré de la classe Animal, toute tentative d'héritage entraînera une erreur de compilation.
• override est obligatoire pour les méthodes/propriétés que vous souhaitez redéfinir.
• Les interfaces sont mises en œuvre avec le mot-clé interface et ne nécessitent pas open.

Question piège

En Kotlin, peut-on hériter de n'importe quelle classe comme en Java ?

Réponse : Non, seulement les classes marquées open (ou abstract). Les classes normales sont finalisées et ne peuvent pas être héritées. Cela a été fait pour améliorer la sécurité et la prévisibilité du code.

Exemple de code incorrect :

class Animal
class Dog : Animal() // Erreur de compilation : "Animal" est final

Exemples d'erreurs réelles dues à l'ignorance des subtilités du sujet

---

Histoire

Dans un projet pour la plateforme Android, un jeune développeur a essayé d'hériter d'un composant personnalisé d'une classe View personnalisée, en oubliant d'ajouter open. Le build a échoué, la cause n'était pas évidente, et les délais ont glissé. Le problème n'a été découvert qu'après une lecture attentive du message du compilateur.

---

Histoire

Lors du développement du SDK, la spécification exigeait une classe de base extensible, mais elle a été déclarée sans open. Après la livraison aux clients, il est apparu que la bibliothèque ne pouvait pas être étendue sans modifications du code source. Une mise à jour a dû être publiée.

---

Histoire

Dans un des projets, un ancien code Java a été migré vers Kotlin, en oubliant la fermeture des classes par défaut. La plupart des tests unitaires utilisant des mocks ont cessé de se compiler, ce qui a ralenti le processus de publication. Ce n'est qu'après avoir ajouté massivement open que le problème a été résolu.