Réponse.

Historique de la question :

Kotlin a combiné le meilleur de Java et de l'héritage fonctionnel de la JVM. Les classes ordinaires sont déclarées comme des structures standard, les classes abstraites permettent de créer des modèles non définis avec une implémentation par défaut, et les interfaces prennent en charge l'héritage multiple de comportements sans état.

Problème :

Le choix correct entre une classe, une classe abstraite et une interface détermine l'architecture de l'application, la granularité du code et son extensibilité. Un héritage incorrect entraîne des difficultés de test et de futurs changements.

Solution :

En Kotlin :

Classe ordinaire : définit la structure et le comportement. Peut être héritée si déclarée ouverte.
Classe abstraite : ne peut pas être instanciée directement. Peut contenir des méthodes d'implémentation et/ou abstraites (sans corps).
Interface : implicitement ouverte, implémente des contrats, permet l'implémentation de méthodes mais ne conserve pas d'état (uniquement des propriétés sans champ de soutien).

Exemple de code :

interface Drawable {
    fun draw()
}

abstract class Shape(var color: String) : Drawable {
    abstract fun calcArea(): Double
    override fun draw() = println("Shape drawn")
}

class Circle(color: String, val radius: Double) : Shape(color) {
    override fun calcArea() = Math.PI * radius * radius
}

Caractéristiques clés :

Les interfaces permettent la multiple implémentation, les classes abstraites — uniquement une seule
Les interfaces ne peuvent pas stocker d'état, les classes abstraites peuvent
Une classe abstraite peut implémenter certaines interfaces et contenir sa propre logique commune

Questions piégées.

Les interfaces peuvent-elles contenir des propriétés avec un champ de soutien ?

Non, elles peuvent seulement définir la signature d'une propriété, mais ne peuvent pas stocker de données — propriétés sans champ de soutien.

Peut-on hériter de plusieurs classes ?

Non, Kotlin ne prend en charge que l'héritage unique de classes, mais l'implémentation multiple d'interfaces.

Peut-on déclarer un constructeur dans une interface ?

Non, une interface ne prend pas en charge les constructeurs car elle ne conserve pas d'état — uniquement le contrat de comportement.

Erreurs typiques et anti-patrons

Utiliser une classe abstraite au lieu d'une interface sans nécessité
Stocker un état dans une interface (impossible, mais des erreurs se produisent lors de la conception)
Concevoir des hiérarchies de classes qui compliquent l'extension

Exemple de la vie réelle

Cas négatif

Dans l'application, toutes les fonctions communes ont été déplacées dans une classe abstraite, même s'il n'y avait pas de logique interne ou d'état, mais simplement un contrat commun.

Avantages :

Un point de changement pour la logique commune

Inconvénients :

Problèmes d'héritage multiple, intégration difficile avec d'autres structures

Cas positif

Seulement les contrats nécessaires ont été déplacés dans des interfaces, les classes abstraites ont été limitées à des propriétés et méthodes communes nécessitant une implémentation.