Principes SOLID en C# : théorie et pratique de A à Z

Formateur Python en ligne pour débutants

Apprenez Python facilement sans surcharge théorique. Résolvez des tâches pratiques avec vérification automatique et écrivez du code directement dans le navigateur.

Start Course

Introduction : pourquoi les principes SOLID en C# ?

Chaque développeur C# rencontre tôt ou tard le problème du « code sale » : des classes qui font tout et n'importe quoi, des dépendances illisibles et l'impossibilité d'apporter des modifications sans risquer de casser tout le projet. SOLID est l'acronyme de cinq principes fondamentaux de conception orientée objet, formulés par Robert Martin. Ils aident à créer un code C# (.NET) flexible, maintenable et testable.

Dans cet article, nous allons décomposer chaque principe SOLID avec une base théorique et des exemples pratiques en C#. Vous apprendrez à les appliquer dans des projets réels, en évitant les erreurs typiques.

1. Single Responsibility Principle (SRP) — Principe de responsabilité unique

Théorie

Une classe ne doit avoir qu'une seule raison de changer. En d'autres termes, chaque classe est responsable d'une seule partie de la fonctionnalité du programme. La violation du SRP conduit à ce qu'une modification d'une opération (par exemple, la sauvegarde en base de données) affecte la logique de calcul ou d'affichage.

Pratique en C#

Considérons un exemple typique de violation du SRP : une classe qui calcule simultanément le salaire et sauvegarde l'employé dans la base de données :

// ❌ Violation du SRP : la classe fait trop de chosespublic class Employee{    public string Name { get; set; }    public decimal Salary { get; set; }

    public decimal CalculateBonus()    {        return Salary * 0.1m;    }

    public void SaveToDatabase()    {        // Logique de sauvegarde en BDD        Console.WriteLine("Employé sauvegardé en BDD");    }}

Corrigeons la situation en séparant les responsabilités :

// ✅ SRP : chaque classe est responsable de sa tâchepublic class Employee{    public string Name { get; set; }    public decimal Salary { get; set; }}

public class BonusCalculator{    public decimal Calculate(Employee employee)    {        return employee.Salary * 0.1m;    }}

public class EmployeeRepository{    public void Save(Employee employee)    {        Console.WriteLine("Employé sauvegardé en BDD");    }}

2. Open-Closed Principle (OCP) — Principe d'ouverture/fermeture

Théorie

Les entités logicielles (classes, modules, fonctions) doivent être ouvertes à l'extension, mais fermées à la modification. Cela signifie que vous pouvez ajouter de nouvelles fonctionnalités sans modifier le code existant.

Pratique en C#

Supposons que nous devions calculer l'aire de différentes formes. Une violation de l'OCP consiste à utiliser des if-else ou des switch pour chaque nouveau type de forme :

// ❌ Violation de l'OCP : l'ajout d'une nouvelle forme nécessite de modifier le codepublic class AreaCalculator{    public double Calculate(object shape)    {        if (shape is Circle circle)            return Math.PI * circle.Radius * circle.Radius;        else if (shape is Rectangle rect)            return rect.Width * rect.Height;        // En ajoutant Triangle, il faudrait ajouter un autre if        return 0;    }}

La solution consiste à utiliser l'abstraction et le polymorphisme :

// ✅ OCP : extension par héritage sans toucher au code existantpublic abstract class Shape{    public abstract double GetArea();}

public class Circle : Shape{    public double Radius { get; set; }    public override double GetArea() => Math.PI * Radius * Radius;}

public class Rectangle : Shape{    public double Width { get; set; }    public double Height { get; set; }    public override double GetArea() => Width * Height;}

public class AreaCalculator{    public double Calculate(Shape shape)    {        return shape.GetArea(); // Fonctionne pour n'importe quelle forme    }}