1. Introduction
L'héritage en programmation, c'est un peu comme l'héritage dans la vraie vie. Par exemple, tu peux hériter de tes parents la couleur des yeux, la forme du nez ou même un talent pour le dessin. Tu reçois ces traits "par défaut", t'as pas besoin de les créer à partir de zéro. Mais tu peux aussi développer tes propres caractéristiques uniques, que tes parents n'ont pas.
En programmation, ça marche pareil :
- Une classe (on va l'appeler classe de base ou classe parente, parfois superclasse) définit des caractéristiques communes (propriétés) et des comportements (méthodes) que tous ses "descendants" auront.
- Une autre classe (appelée classe dérivée ou classe enfant, parfois sous-classe) hérite tous ces trucs communs de son parent. Elle récupère automatiquement toutes les propriétés et méthodes public et protected de la classe de base. Pas besoin de les redéclarer.
- En plus, la classe dérivée peut ajouter ses propres propriétés et méthodes uniques, que la classe parente n'a pas.
- Parfois, la classe dérivée peut même modifier le comportement des méthodes héritées (mais on verra ça dans les prochaines leçons, ça s'appelle le polymorphisme).
Le concept clé de l'héritage, c'est la phrase "est-un" (is-a relationship). Imagine que tu codes ton propre jeu avec des mages, des guerriers et des archers :
- Guerrier est un Personnage.
- Mage est un Personnage.
- Archer est un Personnage.
Si Guerrier est un Personnage, alors il doit avoir tout ce qu'a n'importe quel Personnage, plus des trucs à lui, uniques pour le Guerrier.
2. Syntaxe de l'héritage
Regardons un exemple et tapons un peu de code.
Bases de la syntaxe
// Classe de base
public class Animal
{
public string Name { get; set; }
public void Move()
{
Console.WriteLine($"{Name} se déplace.");
}
}
// Classe enfant
public class Dog : Animal
{
public void Bark()
{
Console.WriteLine($"{Name} aboie : Ouaf !");
}
}
Mate les deux-points après le nom de la classe Dog. Ici, on dit : Dog hérite de tout ce qu'il y a dans Animal.
Tout ce qui est public et protected dans Animal sera aussi dans Dog !
Utilisation de l'héritage
Essayons d'utiliser ces classes dans notre appli console :
var dog = new Dog();
dog.Name = "Rex"; // propriété Name héritée de Animal
dog.Move(); // méthode Move héritée de Animal
dog.Bark(); // méthode propre à Dog
// Affichage :
// Rex se déplace.
// Rex aboie : Ouaf !
On peut aussi créer un chat, histoire de varier un peu le "zoo" :
public class Cat : Animal
{
public void Meow()
{
Console.WriteLine($"{Name} miaule : Miaou !");
}
}
var cat = new Cat();
cat.Name = "Whiskers";
cat.Move();
cat.Meow();
3. Comment l'héritage te fait gagner du temps
Quand t'as plusieurs entités qui se ressemblent, pas besoin de copier le code à chaque fois. L'héritage, c'est comme une master-copy : tu définis la logique une fois, et tous les descendants la récupèrent.
Visualisation : Arbre d'héritage
. Animal
/ \
Dog Cat
| Classe | Propriété Name | Méthode Move | Méthode propre |
|---|---|---|---|
| Animal | + | + | - |
| Dog | + | + | Bark() |
| Cat | + | + | Meow() |
Encore un exemple — étendre une appli
Imaginons qu'on veut créer un système pour gérer différents types de personnes. Souviens-toi de l'approche d'avant :
public class Person
{
public string FirstName { get; set; }
public string LastName { get; set; }
}
// Maintenant on ajoute un employé
public class Employee
{
public string FirstName { get; set; }
public string LastName { get; set; }
public string Position { get; set; }
}
Pas super pratique ! Les infos sur le nom sont dupliquées. Avec l'héritage, c'est plus propre :
public class Person
{
public string FirstName { get; set; }
public string LastName { get; set; }
}
public class Employee : Person
{
public string Position { get; set; }
}
public class Student : Person
{
public int Grade { get; set; }
}
Maintenant, Employee et Student ont déjà FirstName et LastName — pas besoin de les écrire deux fois. Tu vois, tu peux facilement étendre le système pour d'autres rôles.
C'est ça la magie de l'héritage : on décrit les trucs communs une fois dans la classe de base, puis on "étend" juste la fonctionnalité dans les classes dérivées en ajoutant des détails spécifiques.
4. Avantages de l'héritage
Réutilisation du code (Code Reusability) : C'est l'avantage le plus évident. Pas besoin d'écrire le même code à plusieurs endroits. Tu l'écris une fois — tu l'utilises plein de fois. Ton code devient plus sec et plus propre (dans le monde du dev, on dit "Don't Repeat Yourself" — DRY, "Ne te répète pas").
Maintenance plus facile (Easier Maintenance) : Si tu dois changer la logique du déplacement, tu le fais à un seul endroit — dans la classe de base Animal. Toutes les classes dérivées récupèrent automatiquement ce changement. Imagine le temps que ça fait gagner dans un gros projet !
Création de hiérarchies (Creating Hierarchies) : L'héritage permet de modéliser des relations "est-un" du monde réel, en créant des structures logiques et claires. Guerrier est un Personnage, Mage est un Personnage. Ça rend ton code plus structuré et plus facile à comprendre.
Base pour le polymorphisme : Même si on n'a pas encore vu le polymorphisme en détail, l'héritage en est la base. Le polymorphisme te permet de bosser avec des objets de différentes classes dérivées en utilisant l'interface commune de la classe de base. Par exemple, tu pourras avoir une liste de tous les Animal (que ce soit Dog, Cat ou d'autres animaux) et appeler leur méthode Move sans te soucier du type précis de chaque animal. C'est super puissant, et on va en reparler !
5. Nuances et particularités de l'héritage
Héritage simple en C# : Contrairement à certains autres langages (genre C++), C# ne supporte que l'héritage simple. Ça veut dire qu'une classe ne peut hériter que d'une seule classe de base. Tu peux pas hériter à la fois de Animal et, disons, de Vehicle (si une telle classe existait).
Toutes les classes héritent implicitement de object : Fun fact ! Si tu ne précises pas de classe de base, ta classe hérite automatiquement de System.Object. C'est la classe la plus basique du .NET, et elle fournit des méthodes fondamentales comme ToString(), Equals(), GetHashCode(). Donc, quand tu overrides ToString() dans tes classes, en fait tu overrides une méthode héritée de object !
Les constructeurs ne sont pas hérités : Une classe dérivée n'hérite pas des constructeurs de la classe de base. Tu dois définir explicitement les constructeurs dans la classe dérivée. Mais si la classe de base a un constructeur avec des paramètres, tu DOIS appeler un des constructeurs de la classe de base depuis le constructeur de la classe dérivée. Ça se fait avec le mot-clé base.
Les membres privés ne sont pas accessibles : Les membres private de la classe de base ne sont pas accessibles directement depuis la classe dérivée. Ils existent dans l'objet, mais tu peux pas y accéder par leur nom dans le code de la classe dérivée. Si tu veux que des membres soient accessibles aux classes dérivées mais pas au monde entier, utilise le modificateur d'accès protected.
6. Visualisation de la hiérarchie
Pour mieux piger les relations d'héritage, on utilise souvent des diagrammes. Un des plus courants, c'est le diagramme de classes UML (Unified Modeling Language). Pour notre exemple avec les animaux, ça ressemblerait à ça :
classDiagram
class Animal {
+ string Name
+ Move()
}
class Dog {
+ Bark()
}
class Cat {
+ Meow()
}
Animal <|-- Dog : hérite
Animal <|-- Cat : hérite
Sur ce diagramme, la flèche avec un triangle vide (de Dog vers Animal, de Cat vers Animal) veut dire relation d'héritage : "est-un" (is-a relationship).
7. Application pratique de l'héritage
L'héritage, c'est pas juste un concept académique, c'est un des piliers de la prog moderne, super utilisé dans les vrais projets :
Développement d'interface graphique (GUI) : Dans WPF, WinForms, MAUI (frameworks pour créer des applis desktop en .NET), presque tous les contrôles (boutons, champs texte, fenêtres) héritent d'une classe de base commune Control ou UIElement. Ça leur permet d'avoir des propriétés communes comme la taille, la position, la visibilité, et des méthodes communes comme la gestion des événements.
Par exemple, Button est un Control, et TextBox est un Control.
Moteurs de jeux : L'héritage est parfait pour créer des hiérarchies d'objets de jeu : GameObject → Character → Player/Enemy ou Vehicle → Car/Motorcycle.
Travail avec les bases de données (ORM) : Dans des frameworks comme Entity Framework Core, tu définis souvent une classe de base pour toutes tes entités, genre BaseEntity, qui peut contenir des propriétés comme Id (identifiant en base) ou CreatedAt (date de création). Toutes tes entités concrètes (User, Product, Order) vont hériter de BaseEntity et récupérer ces propriétés automatiquement.
Tests : L'héritage est utilisé dans les frameworks de tests (genre xUnit, NUnit), où tu peux créer des classes de test de base avec la logique commune d'init et de clean, dont héritent les classes de test concrètes.
Librairies et frameworks : Même la bibliothèque standard .NET utilise à fond l'héritage. Par exemple, plein de collections et de types héritent de classes de base communes ou implémentent des interfaces communes (on en parlera plus tard).
En entretien C#/.NET, les questions sur l'héritage, ses principes (DRY, "is-a"), et ses différences avec d'autres concepts (genre composition ou interfaces) sont basiques et super fréquentes. Savoir expliquer ce que c'est, mais aussi donner des exemples de la vraie vie ou de code — c'est super précieux.
Tu vois, l'héritage, c'est pas juste un "truc" du langage, c'est un outil puissant pour structurer ton code, éviter la duplication et créer des systèmes logiquement liés. C'est la clé pour écrire du code scalable et maintenable.
GO TO FULL VERSION