Problèmes et limites de l’héritage

1. Limites de l’héritage en Java

Héritage simple uniquement pour les classes. En Java, une classe ne peut hériter que d’une seule autre classe. C’est ce qu’on appelle l’héritage simple. Par exemple, ceci — autorisé :

class Animal { }
class Dog extends Animal { }

Mais ceci — interdit :

class Animal { }
class Robot { }
// ERREUR ! Java ne prend pas en charge l’héritage multiple de classes
class RoboDog extends Animal, Robot { }

Si vous essayez de déclarer une telle classe, le compilateur indiquera : "class RoboDog cannot extend multiple classes". Pourquoi ? Parce que l’héritage multiple entraîne des ambiguïtés : si les deux parents possèdent une méthode avec la même signature, laquelle utiliser ? C’est le fameux « problème du diamant » (diamond problem).

Les interfaces en Java peuvent être implémentées en nombre illimité, mais nous ne les avons pas encore étudiées. Nous en parlerons plus tard.

Les constructeurs ne sont pas hérités. Même si vous avez une classe parente avec un constructeur pratique, ce constructeur n’apparaîtra pas automatiquement dans la classe fille. Il faut appeler explicitement le constructeur du parent via super(...) dans le constructeur de la classe fille.

Les membres privés ne sont pas hérités. Tous les champs et méthodes private du parent sont inaccessibles dans la classe fille. Ils existent « à l’intérieur » de l’objet, mais on ne peut pas y accéder directement.

2. Problèmes des hiérarchies fragiles

Couplage fort entre les classes. Lorsque vous créez une hiérarchie de classes, les sous-classes deviennent étroitement couplées à la classe parente. Si vous modifiez la classe de base, cela peut affecter (voire casser) toutes ses sous-classes. Imaginez que vous avez une classe Animal, dont héritent Dog, Cat, Bird et une dizaine d’autres. Si vous changez la structure de Animal (par exemple en ajoutant un nouveau paramètre obligatoire au constructeur), il faudra parcourir toutes les classes filles et mettre à jour leur code. C’est particulièrement douloureux dans les grands projets.

Le problème d’un héritage « cassant ». Parfois, une sous-classe peut modifier involontairement le comportement attendu par la classe de base. Par exemple, la classe parente appelle sa propre méthode à l’intérieur d’une autre méthode, et la sous-classe redéfinit cette méthode et en change la logique. Résultat : la classe parente ne fonctionne plus comme prévu.

class Animal {
    void makeSound() {
        System.out.println("Some sound");
    }
    void sleep() {
        System.out.println("Animal is going to sleep...");
        makeSound(); // Le parent appelle sa propre méthode
    }
}

class Dog extends Animal {
    @Override
    void makeSound() {
        System.out.println("Woof!");
    }
}

public class Main {
    public static void main(String[] args) {
        Animal a = new Dog();
        a.sleep();
    }
}

Que va afficher le programme ?

Animal is going to sleep...
Woof!

La classe parente supposait que makeSound() — c’était sa propre implémentation, mais en réalité c’est la version de la sous-classe qui sera appelée ! Cela peut entraîner des bugs inattendus si la sous-classe redéfinit une méthode avec une logique différente.

3. Le problème de la classe de base fragile (fragile base class problem)

C’est un problème réel dans les grands projets. Si vous modifiez la classe de base (par exemple, vous ajoutez un champ, vous changez l’implémentation d’une méthode), vous risquez de casser le comportement de toutes les sous-classes. Parfois, cela ne se manifeste pas immédiatement, et la recherche de cette erreur peut prendre des heures, voire des jours.

Illustration : supposons que vous ayez une classe Shape avec une méthode draw(). Vous décidez d’ajouter dans Shape une nouvelle méthode drawShadow(), qui appelle draw(). Mais l’une des sous-classes (Circle) redéfinit draw(), et désormais, lors de l’appel de drawShadow() sur Circle, le comportement peut s’avérer inattendu.

4. Couplage fort et difficultés de refactorisation

Quand les classes sont liées par héritage, la modification d’une classe peut affecter toute une chaîne de dépendances. Cela rend le code moins flexible, complique la refactorisation et l’extension. Il arrive qu’il faille réécrire des hiérarchies entières pour ajouter une nouvelle fonctionnalité.

Exemple concret

class Vehicle { /* ... */ }
class Car extends Vehicle { /* ... */ }
class Bicycle extends Vehicle { /* ... */ }
class Bus extends Vehicle { /* ... */ }

Soudain, une nouvelle exigence arrive : « Et si on ajoutait une trottinette électrique ? ». Mais une trottinette électrique est à la fois un moyen de transport et un gadget. Que faire ? Si vous commencez à étendre la hiérarchie pour y caser toutes les nouvelles entités, elle deviendra rapidement ingérable.

5. Problème de réutilisation de code sans lien logique

Très souvent, les débutants (et pas seulement) utilisent l’héritage pour réutiliser du code, même lorsqu’il n’existe pas de relation « est un » (is-a) entre les classes. Cela conduit à une architecture incorrecte.

Exemple d’héritage incorrect

class DatabaseUtils {
    void connect() { /* ... */ }
    void disconnect() { /* ... */ }
}

class User extends DatabaseUtils { // Un utilisateur n'est pas un utilitaire de base de données !
    String name;
}

Il est préférable d’utiliser la composition : faire de DatabaseUtils une classe séparée et appeler ses méthodes là où c’est nécessaire, plutôt que d’en hériter.

6. Alternatives à l’héritage

Composition (has-a)

Si un objet « contient » un autre objet, utilisez la composition. Par exemple, une classe Car peut avoir un champ Engine :

class Engine { /* ... */ }

class Car {
    private Engine engine;
    // ...
}

Délégation

Au lieu d’étendre une classe, déléguez la réalisation d’une tâche à un autre objet. Cela conserve la flexibilité et réduit le couplage des composants.

Interfaces

En Java, une classe peut implémenter autant d’interfaces qu’elle le souhaite. Cela permet de combiner des comportements de manière flexible sans hiérarchie rigide. Nous reviendrons sur les interfaces plus tard.

Quand faut-il utiliser l’héritage ?

Utilisez l’héritage uniquement s’il existe une relation claire « est un » (is-a) entre les classes :

• Un chat est un animal (Cat extends Animal)
• Un cercle est une figure (Circle extends Shape)
• Un administrateur est un utilisateur (Admin extends User)

N’utilisez pas l’héritage uniquement pour réutiliser du code — la composition et la délégation sont là pour ça.

7. Quelques exemples pratiques

Exemple : une hiérarchie trop complexe

class Animal { }
class Mammal extends Animal { }
class Cat extends Mammal { }
class PersianCat extends Cat { }
class SuperPersianCat extends PersianCat { }

Si votre hiérarchie dépasse trois niveaux — posez-vous la question : ne faudrait-il pas s’arrêter ? Des hiérarchies trop profondes compliquent la compréhension et la maintenance du code.

Exemple : hiérarchie plate

class Animal { }
class Cat extends Animal { }
class Dog extends Animal { }
class Bird extends Animal { }
class Fish extends Animal { }
class Spider extends Animal { }
class Platypus extends Animal { }
class Dragon extends Animal { }

Si vous avez des dizaines de sous-classes qui ne diffèrent que par une seule méthode, il est peut-être préférable d’utiliser des interfaces ou la composition.

8. Erreurs courantes lors de l’utilisation de l’héritage

Erreur n° 1 : héritage sans relation « est un ».
Si la classe dérivée n’est en réalité pas une spécialisation du parent, l’architecture devient artificielle et devient vite incontrôlable. Par exemple, la classe User ne doit pas hériter de DatabaseUtils, même si cela semble « pratique ».

Erreur n° 2 : redéfinir des méthodes en modifiant le contrat.
Si vous redéfinissez une méthode et changez sa logique de sorte qu’elle ne corresponde plus aux attentes du parent, cela entraînera des erreurs inattendues. Par exemple, si la classe de base s’attend à ce que la méthode draw() dessine une figure, et que dans la sous-classe elle se met soudain à effectuer des effets de bord dangereux — c’est catastrophique.

Erreur n° 3 : hiérarchies trop profondes ou trop plates.
Une hiérarchie trop profonde rend le code difficile à comprendre ; une hiérarchie trop plate entraîne des duplications.

Erreur n° 4 : tenter de contourner les limitations du langage.
Essayer d’implémenter l’héritage multiple avec des « rustines » (copier-coller, superclasses « utilitaires ») mène au chaos.

Erreur n° 5 : utilisation aveugle de l’héritage pour réutiliser du code.
Cela conduit souvent à des liens inattendus entre les classes, complique les tests et la maintenance. Utilisez la composition et la délégation.