Héritage

Chaque année, le même code apparaît en TP :

1class Moteur  { int puissance; void demarrer() { ... } }2class Voiture extends Moteur { String marque; }

Le raisonnement est compréhensible : une voiture a une puissance, une voiture démarre, et Moteur possède déjà les deux. Hériter évite de réécrire.

Le résultat est pourtant une faute de conception, et elle se voit à une conséquence : partout où le programme attend un Moteur, on pourra désormais lui donner une Voiture. Un atelier de réparation de moteurs acceptera une voiture entière. Une liste de moteurs en stock contiendra des véhicules.

Ce chapitre donne le mécanisme de l'héritage, puis le critère qui dit quand on a le droit de s'en servir. Le second compte plus que le premier — c'est le deuxième point qui coince du semestre.

Le mécanisme

1public class Document {2    protected String titre;3    private int identifiant;4 5    public Document(String titre) { this.titre = titre; }6    public String decrire() { return "Document : " + titre; }7}8 9public class Livre extends Document {10    private String auteur;11 12    public Livre(String titre, String auteur) {13        super(titre);                 /* appelle le constructeur du parent */14        this.auteur = auteur;15    }16 17    @Override18    public String decrire() {19        return super.decrire() + ", par " + auteur;20    }21}

Quatre points à relever.

extends établit la relation. Livre est un Document : il hérite de tous les membres non privés de son parent — attributs et méthodes — et peut en ajouter.

Les attributs privés du parent existent mais sont inaccessibles. Chaque Livre contient bien un identifiant en mémoire ; simplement, le code de Livre ne peut pas le lire directement. Il doit passer par un accesseur du parent, s'il en existe un. C'est l'encapsulation du chapitre 3, qui s'applique aussi aux filles — et c'est ce qui justifie l'existence de protected.

super(...) appelle le constructeur du parent, et doit être la première instruction. La raison est de bon sens : la partie parente de l'objet doit être valide avant qu'on ne complète la partie fille. Si on l'omet, Java insère un super() sans argument — et si le parent n'a pas de constructeur sans argument, le code ne compile pas. C'est une erreur fréquente et son message est déroutant.

@Override n'est pas décoratif. Cette annotation demande au compilateur de vérifier qu'une méthode du parent est bien redéfinie. Sans elle, une faute de frappe — decrir() au lieu de decrire() — crée une nouvelle méthode qui ne sera jamais appelée à la place de l'autre, et tout compile. Il faut la mettre systématiquement.

Redéfinir, et prolonger

Redéfinir (override), c'est fournir dans la fille une méthode de même signature que dans le parent. C'est elle qui sera exécutée sur un objet de la fille — le chapitre 6 dira précisément pourquoi.

super.decrire() appelle la version du parent depuis la fille. C'est ce qui permet de prolonger un comportement au lieu de le remplacer : faire ce que fait le parent, puis ajouter. L'oubli de cet appel est une source classique de bogues — une fille qui redéfinit initialiser() sans appeler celle du parent laisse la moitié de l'objet non initialisée.

Trois interdits à connaître. On ne peut pas restreindre la visibilité en redéfinissant : une méthode public ne peut pas devenir protected chez la fille, sinon un objet fille vu comme un parent perdrait une méthode qu'il est censé avoir. On ne peut pas redéfinir une méthode final. Et une méthode static n'est pas redéfinie mais masquée, ce qui est un piège dont le chapitre 6 montrera l'effet.

Une hiérarchie d'héritage se lit d'un coup d'œil sous forme de graphe. Dans le diagramme interactif ci-dessous, chaque flèche part d'une sous-classe et pointe vers son parent (extends) : Livre, Magazine et CD sont des Document et héritent de son titre et de sa méthode afficher(). Déplacez les nœuds pour explorer la structure.

Le test « est-un »

Voici le vrai sujet du chapitre.

Avant d'écrire extends, on formule la phrase à voix haute : « Un B est-il un A ? »

1Un Livre est un Document.          ✔  cohérent2Un Rectangle est une Forme.        ✔3Un Étudiant est une Personne.      ✔4Une Voiture est un Moteur.         ✘  non — elle en POSSÈDE un5Un Compte est une Banque.          ✘  non — il appartient à une banque6Une Commande est une ListeArticles ✘  non — elle en contient une

Le test échoue le plus souvent de la même façon : on hérite parce qu'on a repéré des attributs communs, ce qui est un argument de réutilisation, pas de nature.

Il faut aller un cran plus loin, car « est-un » reste parfois trompeur. Le critère rigoureux est le suivant : tout ce qui est vrai d'un objet de la classe mère doit rester vrai d'un objet de la classe fille. Autrement dit, un code écrit pour le parent doit continuer de fonctionner correctement si on lui donne une fille — sans le savoir.

Le contre-exemple d'école est celui du carré et du rectangle. Un carré est un rectangle, en mathématiques. Et pourtant :

1class Rectangle { void setLargeur(double l); void setHauteur(double h); double aire(); }2class Carre extends Rectangle { /* setLargeur modifie aussi la hauteur */ }

Un code écrit pour Rectangle peut légitimement faire : fixer la largeur à 5, fixer la hauteur à 4, et attendre une aire de 20. Sur un Carre, il obtient 16. Le code du parent est cassé par la fille, alors même que la phrase « est-un » était vraie.

La leçon est double. La relation « est-un » porte sur le COMPORTEMENT, pas sur le vocabulaire. Et quand un héritage force à écrire des exceptions dans le parent — « sauf si c'est un carré » — c'est le signe qu'il faut le défaire.

Héritage contre composition

Quand « est-un » échoue, la bonne relation est presque toujours « a-un » — la composition.

1public class Voiture {2    private final Moteur moteur;          /* une Voiture A UN moteur */3    private String marque;4 5    public Voiture(String marque, Moteur moteur) {6        this.marque = marque;7        this.moteur = moteur;8    }9 10    public void demarrer() {11        moteur.demarrer();                /* délégation */12    }13}

Le code de Moteur n'est toujours pas dupliqué : il est appelé, au lieu d'être hérité. Et la relation absurde disparaît — aucune Voiture ne peut plus se faire passer pour un Moteur.

Quatre avantages, qui expliquent la recommandation générale de préférer la composition.

On n'expose que ce qu'on veut. L'héritage rend publiques toutes les méthodes publiques du parent, y compris celles qui n'ont aucun sens pour la fille. La composition ne délègue que ce qu'on choisit.

On peut changer de composant à l'exécution — remplacer le moteur — ce qu'un lien d'héritage, fixé à la compilation, ne permet pas.

On peut en avoir plusieurs. Une Voiture a quatre Roue ; l'héritage ne saurait pas l'exprimer.

Le couplage est plus faible. Une fille dépend des détails internes de son parent : une modification du parent peut casser toutes ses filles, sans qu'aucune signature n'ait changé. C'est le « problème de la classe de base fragile », et il n'a pas d'équivalent en composition.

La règle de conduite, à retenir telle quelle : héritage quand la relation est vraiment « est-un » et que la substituabilité tient ; composition dans tous les autres cas — c'est-à-dire le plus souvent.

À vous

L'exercice attaque les deux difficultés du chapitre dans l'ordre.

D'abord un jeu de paires candidates — Livre/Document, Voiture/Moteur, Carre/Rectangle et quelques autres — sur lesquelles vous appliquez le test « est-un » et justifiez votre verdict. Le corrigé donne le raisonnement, pas seulement la réponse.

Ensuite la démonstration mécanique de la rupture : un test écrit pour Rectangle — fixer deux dimensions, vérifier l'aire — que vous exécutez sur un Rectangle puis sur un Carre. Le même test passe puis échoue, sans avoir été modifié. C'est la définition opérationnelle de la substituabilité, et elle vaut mieux qu'un long discours.

Enfin la refonte de Voiture extends Moteur en composition, avec délégation — et la vérification qu'une Voiture ne peut plus être rangée dans une liste de moteurs.

// ── 1. Le test « est-un » ─────────────────────────────────────────────────
const PAIRES = [
  { fille: "Livre",    mere: "Document",      indice: "un livre est un document" },
  { fille: "Voiture",  mere: "Moteur",        indice: "une voiture démarre, et a une puissance" },
  { fille: "Etudiant", mere: "Personne",      indice: "un étudiant a un nom et un âge" },
  { fille: "Compte",   mere: "Banque",        indice: "un compte appartient à une banque" },
  { fille: "Carre",    mere: "Rectangle",     indice: "en mathématiques, c'en est un" },
  { fille: "Pile",     mere: "ArrayList",     indice: "une pile stocke des éléments en liste" },
];

// ← à écrire : pour chaque paire, répondre estUn (true/false) et dire
//   pourquoi. Deux questions : la phrase « une F est une M » est-elle vraie
//   de NATURE ? et un code écrit pour M fonctionnerait-il sur une F ?
const VERDICTS = {};

// ── 2. La substituabilité, mesurée ────────────────────────────────────────
class Rectangle {
  constructor(l, h) { this._largeur = l; this._hauteur = h; }
  setLargeur(l) { this._largeur = l; }
  setHauteur(h) { this._hauteur = h; }
  aire() { return this._largeur * this._hauteur; }
}

class Carre extends Rectangle {
  constructor(cote) { super(cote, cote); }
  setLargeur(l) { this._largeur = l; this._hauteur = l; }   // maintient l'invariant
  setHauteur(h) { this._largeur = h; this._hauteur = h; }
}

// Un test écrit POUR Rectangle, par quelqu'un qui ignore que Carre existe.
function testEcritPourRectangle(forme) {
  forme.setLargeur(5);
  forme.setHauteur(4);
  return { aire: forme.aire(), attendu: 20 };
}

// ── 3. Voiture : héritage fautif, puis composition ────────────────────────
class Moteur {
  constructor(puissance) { this.puissance = puissance; this.tourne = false; }
  demarrer() { this.tourne = true; return "moteur " + this.puissance + " ch démarré"; }
  arreter() { this.tourne = false; }
}

class VoitureHeritee extends Moteur {          // ← la faute
  constructor(marque, puissance) { super(puissance); this.marque = marque; }
}

class Voiture {
  #moteur;
  constructor(marque, moteur) { this.marque = marque; this.#moteur = moteur; }
  // ← à écrire : déléguer demarrer() au moteur, sans hériter de lui
}

// ── À VOUS ────────────────────────────────────────────────────────────────
// 1. Remplissez VERDICTS pour les six paires.
// 2. Lancez testEcritPourRectangle sur un Rectangle puis sur un Carre.
// 3. Écrivez la délégation dans Voiture, et vérifiez qu'une Voiture ne peut
//    plus être rangée dans une liste de moteurs.

console.log("   " + testEcritPourRectangle(new Rectangle(1, 1)).aire);

En travaux pratiques

Ce que la suite en fait

Le chapitre 6 exploite ce que celui-ci a construit. Puisqu'un Livre est un Document, une variable déclarée Document peut désigner un Livre — et la question devient : quelle version de decrire() s'exécute alors ? C'est le polymorphisme, et c'est l'obstacle de l'année.

Le contre-exemple du carré y trouvera aussi sa vraie sortie : une interface commune, qui ne promet que ce que les deux formes savent réellement tenir.

À retenir