Principe SOLID : les 5 Règles de la Programmation Orientée Objet

Vous écrivez du code qui fonctionne, mais qui devient vite un cauchemar à maintenir ? Chaque modification entraîne des bugs inattendus ? Vous avez l’impression que votre projet est un château de cartes prêt à s’écrouler ?

Ce sont les symptômes d’un code mal conçu. La solution tient en cinq lettres : SOLID. Il s’agit d’un ensemble de principes de programmation orientée objet qui vous aident à créer un logiciel plus simple, plus flexible et plus facile à maintenir. Mis en avant par Robert C. Martin (« Uncle Bob »), ces principes sont la base d’une architecture logicielle saine.

Tableau Récapitulatif des 5 Principes SOLID

Pour comprendre rapidement de quoi il s’agit, voici un résumé. Chaque principe de l’acronyme SOLID est une règle simple pour mieux organiser votre code.

Analyse Détaillée de Chaque Principe SOLID (avec Exemples de Code)

Maintenant, regardons chaque principe de plus près. Pour chaque règle, on va voir pourquoi c’est utile et comment l’appliquer avec des exemples de code concrets. L’idée est de passer de la théorie à la pratique.

S – Le Principe de Responsabilité Unique (Single Responsibility Principle)

Ce principe est le plus simple à comprendre. Il dit qu’une classe doit avoir une seule et unique responsabilité. Si une classe gère à la fois les informations de l’utilisateur ET la connexion à la base de données, elle a deux responsabilités. C’est un problème.

Pourquoi c’est important ? Parce que si vous devez changer la façon dont vous vous connectez à la base de données, vous risquez de casser le code qui gère l’utilisateur. En séparant les responsabilités, vous réduisez les risques de bugs et votre code devient plus facile à tester. Chaque classe fait une seule chose, mais elle la fait bien.

• Le symptôme d’un non-respect : Vous décrivez votre classe en utilisant le mot « et ». Exemple : « Cette classe gère l’utilisateur ET sa sauvegarde ».
• La solution : Séparez les responsabilités en créant deux classes distinctes.

Exemple de code :

// ❌ Mauvaise pratique : une classe avec deux responsabilités
class User {
    get_user_info() { /* ... */ }
    save_user_to_database() { /* ... */ }
}

// ✅ Bonne pratique : chaque classe a une seule responsabilité
class User {
    get_user_info() { /* ... */ }
}

class UserRepository {
    save(User user) { /* ... */ }
}

O – Le Principe Ouvert/Fermé (Open/Closed Principle)

Le principe « Ouvert/Fermé » semble contradictoire, mais il est simple. Votre code doit être :

• Ouvert à l’extension : Vous devez pouvoir ajouter de nouvelles fonctionnalités.
• Fermé à la modification : Vous ne devriez pas avoir à changer le code existant qui fonctionne déjà pour le faire.

Comment c’est possible ? En utilisant des abstractions, comme des interfaces ou des classes de base. Au lieu de modifier une longue série de `if/else` dans une fonction, vous créez une nouvelle classe qui implémente une interface commune. Le code principal ne change pas, il sait juste comment travailler avec l’interface.

Exemple de code :

Imaginons un système qui calcule le montant d’une facture. Au début, il n’y a que des factures normales. Puis, on veut ajouter des factures avec une remise.

// ❌ Mauvaise pratique : on modifie la classe existante
class InvoiceCalculator {
    calculate_total(invoice) {
        if (invoice.type == 'discount') {
            // ... calcul avec remise
        } else {
            // ... calcul normal
        }
    }
}

// ✅ Bonne pratique : on étend avec de nouvelles classes
interface InvoiceType {
    calculate();
}

class NormalInvoice implements InvoiceType {
    calculate() { /* ... */ }
}

class DiscountInvoice implements InvoiceType {
    calculate() { /* ... */ }
}

// Le code principal ne change plus
class InvoiceCalculator {
    calculate_total(InvoiceType invoice) {
        return invoice.calculate();
    }
}

L – Le Principe de Substitution de Liskov (Liskov Substitution Principle)

Ce principe, nommé d’après Barbara Liskov, concerne l’héritage. Il dit que si une classe `Carré` hérite d’une classe `Rectangle`, vous devriez pouvoir utiliser un objet `Carré` partout où un objet `Rectangle` est attendu, sans que le programme ne plante ou ne se comporte bizarrement.

En clair, un sous-type (la classe enfant) doit être parfaitement substituable à son type de base (la classe parent). Si ce n’est pas le cas, c’est que votre héritage est probablement mal conçu. Le non-respect de ce principe conduit souvent à devoir vérifier le type d’un objet avec des `if` avant de l’utiliser, ce qui casse le principe Ouvert/Fermé.

Exemple de code :

L’exemple classique est celui du Rectangle et du Carré. Un carré est un rectangle, non ? En programmation, ce n’est pas si simple. Un rectangle a une largeur et une hauteur indépendantes. Un carré a des côtés égaux. Si `Carré` hérite de `Rectangle`, modifier la largeur doit aussi modifier la hauteur, ce qui n’est pas le comportement attendu d’un `Rectangle`.

// ❌ Mauvaise pratique : le carré change le comportement du rectangle
class Rectangle {
    set_width(w) { this.width = w; }
    set_height(h) { this.height = h; }
}

class Square extends Rectangle {
    // On force les côtés à être égaux, ce qui casse la logique du parent
    set_width(s) { this.width = s; this.height = s; }
    set_height(s) { this.width = s; this.height = s; }
}

// Une fonction qui attend un Rectangle va se comporter bizarrement avec un Carré

La solution ici est de repenser la hiérarchie. Peut-être que `Rectangle` et `Carré` ne devraient pas hériter l’un de l’autre, mais plutôt d’une classe `Forme` plus abstraite. Le but est de garantir que l’héritage a du sens et ne crée pas d’effets de bord.

I – Le Principe de Ségrégation des Interfaces (Interface Segregation Principle)

Ce principe dit qu’un client (une classe qui utilise une interface) ne devrait pas être forcé de dépendre de méthodes qu’il n’utilise pas. En d’autres termes, il vaut mieux avoir plusieurs petites interfaces très spécifiques plutôt qu’une seule grosse interface générale.

Imaginez une interface `Travailleur` avec les méthodes `travailler()`, `manger()` et `dormir()`. Si vous avez une classe `Robot`, elle peut `travailler()`, mais elle n’a pas besoin de `manger()` ou `dormir()`. Elle serait forcée d’implémenter ces méthodes, même pour ne rien faire. C’est le signe d’une mauvaise conception.

• La solution : Découpez la grosse interface en plusieurs interfaces plus petites et cohérentes.
• Le bénéfice : Votre code est plus propre, car les classes implémentent uniquement ce dont elles ont réellement besoin. Cela réduit le couplage.

Exemple de code :

// ❌ Mauvaise pratique : une interface trop grosse
interface Worker {
    work();
    eat();
}

class Human implements Worker { /* ... OK */ }
class Robot implements Worker {
    work() { /* ... OK */ }
    eat() { // Un robot ne mange pas ! Cette méthode est inutile ici. }
}

// ✅ Bonne pratique : des interfaces spécifiques
interface Workable {
    work();
}

interface Eatable {
    eat();
}

class Human implements Workable, Eatable { /* Implémente les deux */ }
class Robot implements Workable { /* Implémente seulement ce dont il a besoin */ }

D – Le Principe d’Inversion des Dépendances (Dependency Inversion Principle)

Ce dernier principe est peut-être le plus important pour une architecture logicielle souple. Il se divise en deux points :

1. Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux doivent dépendre d’abstractions (interfaces).
2. Les abstractions ne doivent pas dépendre des détails. Les détails doivent dépendre des abstractions.

Ça semble compliqué, mais l’idée est simple : ne couplez pas directement vos classes entre elles. Faites-les plutôt communiquer à travers un « contrat », qui est une interface. Par exemple, au lieu que votre classe `Panier` dépende directement d’une classe `PaiementStripe`, elle devrait dépendre d’une interface `PasserelleDePaiement`. Ainsi, si demain vous voulez passer à PayPal, il vous suffit de créer une classe `PaiementPayPal` qui implémente la même interface. Le code du `Panier` n’a pas besoin de changer.

Exemple de code :

// ❌ Mauvaise pratique : dépendance directe à une classe concrète
class MySQLDatabase {
    connect() { /* ... */ }
}

class UserManager {
    private mySQLDatabase;
    // Le UserManager est "collé" à MySQL. Difficile de changer.
    UserManager() {
        this.mySQLDatabase = new MySQLDatabase();
    }
}

// ✅ Bonne pratique : dépendance à une abstraction (interface)
interface Database {
    connect();
}

class MySQLDatabase implements Database { /* ... */ }
class PostgreSQLDatabase implements Database { /* ... */ }

class UserManager {
    private database;
    // On "injecte" la base de données. On peut utiliser MySQL, PostgreSQL, etc.
    UserManager(Database database) {
        this.database = database;
    }
}

Pourquoi les Principes SOLID sont-ils Toujours Cruciaux en 2025 ?

Les principes SOLID ne sont pas nouveaux, mais ils n’ont jamais été aussi importants. Dans un monde de développement rapide, ils servent de garde-fou contre la « dette technique » (le code de mauvaise qualité qui ralentit les projets).

Ces pratiques sont au cœur des méthodologies modernes comme l’Agile et le DevOps. Un code bien structuré selon SOLID est plus facile à tester automatiquement, à déployer et à faire évoluer par sprints. Pour les architectures microservices, où chaque service doit être autonome et remplaçable, les principes d’inversion des dépendances et de responsabilité unique sont fondamentaux.

Enfin, maîtriser SOLID est une compétence clé recherchée dans les entretiens techniques. Savoir expliquer et appliquer ces principes montre que vous n’êtes pas juste un « pisseur de code », mais un développeur qui pense à la qualité et à la maintenabilité sur le long terme.

FAQ – Questions Fréquentes sur les Principes SOLID

Qu’est-ce que le principe SOLID en une phrase ?

C’est un ensemble de cinq bonnes pratiques de conception en programmation orientée objet pour écrire du code facile à maintenir, à comprendre et à étendre.

Qui a inventé les principes SOLID ?

Les principes ont été rassemblés et popularisés par Robert C. Martin (« Uncle Bob »), une figure majeure du mouvement du « Software Craftsmanship » et du « Clean Code ». L’acronyme SOLID lui-même a été introduit plus tard par Michael Feathers.

Doit-on toujours appliquer SOLID à la lettre ?

Non, ce ne sont pas des lois absolues. Ce sont des guides. Pour un petit script ou un prototype, une application stricte peut être excessive. En revanche, pour un projet destiné à vivre et à évoluer, les ignorer est souvent une très mauvaise idée sur le long terme.

Est-ce que SOLID s’applique en dehors de la programmation orientée objet ?

Oui, les idées derrière SOLID sont universelles. Même en programmation fonctionnelle, les concepts de responsabilité unique, d’interfaces claires et de faible couplage restent très pertinents pour créer un logiciel de qualité.

Au final, les principes SOLID ne sont pas juste un ensemble de règles techniques. C’est une philosophie qui pousse à écrire un code plus propre et plus professionnel. Adopter ces pratiques ne rend pas seulement le code meilleur ; ça améliore aussi la collaboration au sein de l’équipe, car tout le monde travaille sur une base plus saine et prévisible.

Le meilleur conseil ? N’essayez pas de tout appliquer d’un coup. Prenez un de vos projets actuels et essayez d’améliorer une classe en appliquant le principe de responsabilité unique, ou de découpler deux modules avec une interface. C’est en pratiquant que ces concepts deviendront une seconde nature.