Principes SOLID en C++ : théorie et pratique avec exemples de code

Principes SOLID en C++ : de la théorie à la pratique

Les principes SOLID sont cinq règles fondamentales de conception orientée objet, formulées par Robert Martin. Ils aident à créer un code flexible, évolutif et facile à maintenir. Dans cet article, nous allons décortiquer chaque principe avec des exemples en C++, de la simple théorie aux cas pratiques réels.

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

Théorie : Chaque classe doit avoir une seule raison de changer. Autrement dit, la classe est responsable d'une seule partie de la fonctionnalité du programme.

Problème : Les développeurs placent souvent dans une même classe la logique de traitement des données, leur sauvegarde et leur affichage à l'écran. Cela viole le SRP.

Pratique en C++ : Séparons la classe Report en trois classes distinctes.

// Mauvais : viole le SRPclass Report {    std::string title;    std::string content;public:    void generate() { /* génération du rapport */ }    void saveToFile(const std::string& filename) { /* sauvegarde dans un fichier */ }    void print() { /* impression */ }};

// Bon : respecte le SRPclass Report {    std::string title;    std::string content;public:    void generate() { /* uniquement la génération */ }};

class ReportSaver {public:    void saveToFile(const Report& report, const std::string& filename) { /* sauvegarde */ }};

class ReportPrinter {public:    void print(const Report& report) { /* impression */ }};

Conclusion : Chaque classe est désormais responsable de sa propre tâche. Le code est devenu plus facile à tester et à modifier.

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 nous devons pouvoir ajouter de nouvelles fonctionnalités sans modifier le code existant.

Pratique en C++ : Utilisons le polymorphisme et les classes abstraites.

#include <iostream>#include <vector>#include <memory>

// Classe de base pour les formesclass Shape {public:    virtual double area() const = 0;    virtual ~Shape() = default;};

class Rectangle : public Shape {    double width, height;public:    Rectangle(double w, double h) : width(w), height(h) {}    double area() const override { return width * height; }};

class Circle : public Shape {    double radius;public:    Circle(double r) : radius(r) {}    double area() const override { return 3.14159 * radius * radius; }};

// Classe pour calculer la surface totale — ne nécessite pas de modification lors de l'ajout de nouvelles formesclass AreaCalculator {public:    double totalArea(const std::vector<std::unique_ptr<Shape>>& shapes) {        double total = 0;        for (const auto& shape : shapes) {            total += shape->area();        }        return total;    }};

int main() {    std::vector<std::unique_ptr<Shape>> shapes;    shapes.push_back(std::make_unique<Rectangle>(4, 5));    shapes.push_back(std::make_unique<Circle>(3));

    AreaCalculator calc;    std::cout << "Total area: " << calc.totalArea(shapes) << std::endl;    return 0;}

Conclusion : Nous pouvons ajouter de nouvelles formes (par exemple, Triangle) sans toucher à AreaCalculator.

3. Liskov Substitution Principle (LSP) — Principe de substitution de Barbara Liskov

Théorie : Les objets d'un programme doivent être remplaçables par des instances de leurs sous-types sans altérer la correction du programme. En termes simples, si vous avez une classe parent et une classe enfant, vous devez pouvoir utiliser l'enfant là où le parent est attendu, et tout doit fonctionner.

Pratique