En bref
L’héritage permet à une classe d’en fonder une autre : la classe enfant reprend automatiquement tout ce que possède et sait faire la classe parent, puis ajoute ou adapte ce qui lui est propre. Pense à une famille de véhicules : la classe Vehicule définit le socle commun — une vitesse, savoir démarrer et s’arrêter — et les classes Voiture et Moto en héritent, chacune ajoutant sa spécialité (un coffre, un guidon) sans jamais réécrire le socle. Le vocabulaire : on dit classe parent (ou mère, ou super-classe) et classe enfant (ou fille, ou sous-classe) ; quand l’enfant remplace une méthode héritée par sa propre version, on parle de redéfinition — et le test qui valide une bonne filiation s’appelle la relation « est un » : une Voiture EST UN Véhicule. L’héritage évite la duplication, organise les familles d’objets — et son abus est le piège classique : hériter n’est pas la réponse à tout.
Tu sais fabriquer des moules — des classes — et en tirer des objets. Vient alors la question qui hante tout programme orienté objet : que faire quand deux moules se ressemblent à 80 % ? Copier-coller le moule est la mauvaise réponse ; la bonne s’appelle l’héritage. Comprendre l’héritage en POO — la filiation entre classes, sa syntaxe, ses limites — est la troisième et dernière marche du triptyque objet entamé avec la vue d’ensemble de la POO.
L’héritage, expliqué avec les mains
Regarde une famille de véhicules. Tous partagent un socle : une vitesse, la capacité de démarrer, d’accélérer, de s’arrêter. Puis chaque type ajoute sa personnalité : la voiture a un coffre et sait le fermer, la moto a un guidon et sait se pencher, le camion a une remorque. Modéliser cela avec des classes indépendantes obligerait à réécrire le socle trois fois — trois copies à maintenir, trois occasions de divergence. L’héritage règle l’affaire en une phrase : on écrit le socle une fois dans une classe parent (Vehicule), et chaque classe enfant (Voiture, Moto) déclare sa filiation — récupérant automatiquement tous les attributs et méthodes du parent, et n’écrivant que sa différence.
Le vocabulaire de famille est fidèle à l’image : classe parent (on dit aussi mère, ou super-classe), classe enfant (fille, sous-classe), et deux mécanismes complètent la panoplie. La redéfinition : l’enfant peut remplacer une méthode héritée par sa propre version — la moto redéfinit demarrer() pour ajouter le coup de kick — le socle reste disponible, la spécialité prime. Et le test de la filiation légitime, à graver avant tout code : la relation « est un ». Une Voiture EST UN Véhicule : héritage justifié. Une Voiture n’EST PAS un Moteur — elle en a un : ici, pas d’héritage, mais un attribut (une voiture qui contient un objet moteur — la « composition », l’autre grand outil d’assemblage). Confondre « est un » et « a un » est l’erreur d’architecture fondatrice ; le test en une phrase l’évite presque toujours.
À quoi ça ressemble dans le code
En Python, la filiation se déclare entre parenthèses : class Voiture(Vehicule): — lis « Voiture hérite de Vehicule ». C’est tout : sans une ligne de plus, tout objet Voiture possède déjà la vitesse et sait démarrer — le socle du parent est là, gratuitement. L’enfant ajoute ensuite son propre constructeur et ses méthodes ; pour compléter le réglage du parent plutôt que le remplacer, la fonction super() fait le pont — super().__init__() dit « fais d’abord le réglage du parent, j’ajoute le mien après » : le geste rituel des constructeurs d’enfants. La redéfinition, elle, ne demande rien de spécial : écrire dans Voiture une méthode demarrer() masque naturellement celle du parent pour les voitures — les autres véhicules gardent l’originale.
En JavaScript, mêmes idées, mots-clés explicites : class Voiture extends Vehicule { … } déclare la filiation (extends se lit « étend » — l’enfant prolonge le parent), et super() joue le même rôle de pont dans le constructor. L’usage ne change pas d’un iota : const v = new Voiture(); v.demarrer(); — l’objet répond avec la version la plus spécifique disponible, la sienne s’il l’a redéfinie, celle du parent sinon. Ce mécanisme de « la version la plus proche gagne » a un nom que tu recroiseras — le polymorphisme — et une conséquence magnifique : une fonction qui manipule des Vehicule — ou un tableau qui en range toute une flotte — fonctionne avec toute la descendance, présente et future. C’est exactement ainsi que sont bâties les grandes bibliothèques de Java et du C++ — des arbres de familles entiers, dont tu viens de comprendre la sève.
Les pièges classiques (et comment les éviter)
Piège 1 : hériter pour réutiliser, sans filiation réelle. « Ma classe Facture a besoin des méthodes de Client, héritons ! » — non : une facture n’EST PAS un client. Le remède est le test « est un », appliqué à voix haute avant chaque extends ; en cas d’échec, la composition (un attribut qui contient l’autre objet) est presque toujours la bonne réponse. Piège 2 : la généalogie mille-feuille. Cinq étages d’héritage (A hérite de B qui hérite de C…) rendent le code illisible — pour savoir ce que fait un objet, on remonte l’arbre en spéléologue. Le remède : un ou deux niveaux suffisent à l’immense majorité des programmes ; au-delà, repenser le découpage.
Piège 3 : oublier super() dans le constructeur de l’enfant. L’enfant qui règle ses nouveautés sans appeler le réglage du parent fabrique des objets à moitié initialisés — la vitesse n’existe pas, plantages en cascade. Le remède : dans un constructeur d’enfant, super() d’abord, spécialités ensuite — réflexe rituel. Piège 4 : redéfinir en changeant le contrat. Si demarrer() du parent renvoie vrai/faux et que la version de l’enfant renvoie un texte, toute fonction qui traite des véhicules en famille se casse — la redéfinition change le comportement, jamais la promesse. Le triptyque objet est complet : vue d’ensemble, moule-exemplaire, filiation. Le sceller demande de la pratique — les classes des exercices Python s’étendent volontiers (un CompteEpargne qui hérite du CompteBancaire est le prolongement classique), et notre guide complet replace la POO dans le grand chemin. Les familles d’objets t’appartiennent désormais — fonde-les avec discernement.
Questions fréquentes
C’est quoi l’héritage en programmation orientée objet ?
Le mécanisme par lequel une classe enfant reprend automatiquement les attributs et méthodes d’une classe parent, puis ajoute ou adapte ce qui lui est propre : Voiture hérite de Vehicule — la vitesse et demarrer() viennent gratuitement, le coffre s’ajoute. On écrit le socle commun une fois, jamais en copies.
Quand utiliser l’héritage plutôt que la composition ?
Applique le test « est un » : une Voiture EST UN Véhicule → héritage ; une Voiture A UN moteur → composition (un attribut contenant l’objet Moteur). Hériter pour simplement réutiliser du code sans vraie filiation est le piège d’architecture classique — dans le doute, la composition est souvent le choix le plus sain.
À quoi sert super() dans une classe enfant ?
À faire le pont vers le parent : dans le constructeur de l’enfant, super() exécute d’abord le réglage du parent (ses attributs de base) avant d’ajouter les spécialités — sans lui, les objets naissent à moitié initialisés. Le réflexe : super() en première ligne du constructeur de tout enfant.
C’est quoi la redéfinition (override) d’une méthode ?
Le fait, pour une classe enfant, de fournir sa propre version d’une méthode héritée : la moto redéfinit demarrer() pour son coup de kick, les autres véhicules gardent l’originale. À l’usage, chaque objet répond avec la version la plus spécifique disponible — en conservant la même promesse que la méthode d’origine.
Sources
- Python.org — la documentation officielle du langage
- MDN Web Docs — la référence JavaScript en français
Cet article a une vocation informative et pédagogique. Les plateformes, outils et formations éventuellement cités le sont à titre d’exemple ; compare plusieurs options avant de t’engager ou de payer.