Les principes SOLID, expliqués avec du code

SOLID désigne cinq principes de conception orientée objet. Bien compris, ils transforment un code rigide en code évolutif. Voici chacun, en une phrase et un exemple.

S — Responsabilité unique

Une classe, une seule raison de changer. Une classe qui calcule et persiste et envoie des mails en a trois : sépare-les.

O — Ouvert/fermé

Ouvert à l’extension, fermé à la modification. Plutôt qu’un if/else géant qu’on édite sans cesse :

interface Forme { double aire(); }
record Cercle(double r) implements Forme { public double aire(){ return Math.PI*r*r; } }
record Carre(double c) implements Forme { public double aire(){ return c*c; } }
// Ajouter une forme = ajouter une classe, sans toucher au code existant.

L — Substitution de Liskov

Un sous-type doit pouvoir remplacer son type de base sans surprise. Si Carre hérite de Rectangle mais casse le comportement attendu de setLargeur, le principe est violé.

I — Ségrégation des interfaces

Mieux vaut plusieurs petites interfaces qu’une grosse. Une classe ne devrait pas être forcée d’implémenter des méthodes qu’elle n’utilise pas.

D — Inversion des dépendances

Dépends d’abstractions, pas d’implémentations. C’est le fondement de l’injection de dépendances :

class Service {
    private final Depot depot; // interface, pas classe concrète
    Service(Depot depot) { this.depot = depot; } // injecté
}

En certif comme en entretien, savoir nommer le principe violé dans un extrait de code vaut mieux que réciter la liste. SOLID est un outil de diagnostic, pas un dogme.