Les design patterns : un vocabulaire, pas une checklist

Un design pattern n'est pas une brique à empiler pour faire « pro ». C'est un nom donné à une solution que tu réinventes déjà sans le savoir — et pouvoir la nommer change tout dans une équipe.

Imagine deux menuisiers. L'un dit « tu sais, l'assemblage où on découpe deux pièces en zigzag pour qu'elles s'emboîtent solidement en angle » ; l'autre dit « une queue d'aronde ». Même solution, mais le second a un mot. Ce mot condense des décennies d'expérience, se transmet en une seconde, et évite les malentendus. Les design patterns sont les queues d'aronde du développeur.

La référence historique, c'est le livre Design Patterns de 1994, signé par quatre auteurs qu'on surnomme le « Gang of Four ». Ils y cataloguent 23 patterns, rangés en trois familles selon le problème qu'ils résolvent :

Ce cours ne va pas les survoler tous les 23 — ce serait un annuaire. On va d'abord poser les principes SOLID, la boussole qui dit pourquoi un design est bon, puis étudier en profondeur cinq patterns que tu croiseras vraiment en PHP, avec des simulateurs pour les sentir agir. On finira par une révélation : Symfony lui-même est un empilement de ces patterns.

SOLID : la boussole avant les patterns

Avant de connaître les solutions toutes faites, il faut savoir reconnaître un bon design d'un mauvais. Cinq principes, un acronyme, et une même obsession : que le changement ne fasse pas tout s'écrouler.

Les patterns sont des solutions ; SOLID dit pourquoi elles sont bonnes. Ce sont cinq principes de conception orientée objet, popularisés par Robert C. Martin sous cet acronyme. Leur fil rouge commun : rendre le code ouvert au changement sans être fragile. Prenons-les un par un, avec le compte que tu voudras.

Strategy : changer d'algorithme sans toucher au reste

Tu as plusieurs façons de faire une même chose — calculer des frais de port, trier, appliquer une remise — et tu veux pouvoir passer de l'une à l'autre sans un buisson de if. Le pattern Strategy encapsule chaque façon dans son propre objet.

Le symptôme qui appelle Strategy, c'est le if/elseif qui gonfle. « Si livraison standard, alors… sinon si express… sinon si point relais… ». Chaque nouveau mode de livraison rouvre la même méthode, rallonge la chaîne, et menace de casser les cas existants — une violation frontale du principe Open/Closed.

interface FraisDePort
{
    public function calculer(int $totalPanier): int;   // en centimes
}

final class Express implements FraisDePort
{
    public function calculer(int $totalPanier): int { return 1200; }
}

final class OffertDesUnSeuil implements FraisDePort
{
    public function __construct(private int $seuil = 5000) {}
    public function calculer(int $totalPanier): int
    {
        return $totalPanier >= $this->seuil ? 0 : 600;   // gratuit au-dessus du seuil
    }
}

// Le client reçoit UNE stratégie et l'utilise sans savoir laquelle.
final class Commande
{
    public function __construct(private FraisDePort $fraisDePort) {}
    public function total(int $panier): int
    {
        return $panier + $this->fraisDePort->calculer($panier);
    }
}

Remarque comme Commande ne contient plus aucun if sur le mode de livraison : elle délègue à la stratégie qu'on lui a confiée. Le simulateur ci-dessous te laisse permuter la stratégie sur un même panier — et l'une d'elles change de comportement selon le montant, ce qu'aucune autre ne fait.

Factory : déléguer la création

Faire un new au milieu de ta logique métier, c'est se marier avec une classe concrète pour toujours. La Factory déporte cette décision ailleurs, pour que ton code parle d'abstractions.

On a déjà rencontré la factory dans le cours repositories & factories, côté DDD. Reprenons-la ici comme pattern de conception général, car elle répond à un problème précis : un new MaClasseConcrete() écrit en plein cœur de ta logique la couple définitivement à cette classe. Impossible d'en changer sans rouvrir ce code.

Un exemple parlant : choisir un moyen de paiement selon un code, sans que le code appelant ne connaisse les classes concrètes.

final class PaiementFactory
{
    public function creer(string $type): MoyenPaiement
    {
        return match ($type) {
            'cb'      => new CarteBancaire(),
            'paypal'  => new PayPal(),
            'virement' => new Virement(),
            default   => throw new MoyenInconnuException($type),
        };
    }
}

// Le client ne connaît que l'abstraction MoyenPaiement.
$paiement = $factory->creer($choixUtilisateur);
$paiement->payer($montant);

Le Gang of Four distingue plusieurs variantes — la Factory Method (une méthode que les sous-classes redéfinissent pour choisir le type produit) et l'Abstract Factory (une factory qui produit des familles d'objets cohérents). En pratique PHP, on rencontre surtout la « factory simple » ci-dessus, moins canonique mais très répandue.

La Factory est le complément naturel du principe de Dependency Inversion : elle est l'endroit — souvent le seul — où l'on assume de nommer une classe concrète, pour que tout le reste du code n'ait à connaître que des abstractions.

Decorator : empiler des comportements

Plutôt que d'ajouter dix options par héritage (et de finir avec une explosion de sous-classes), tu emballes un objet dans un autre qui lui ajoute une capacité. Et tu peux emballer l'emballage.

Suppose que tu veuilles ajouter des comportements optionnels à un traitement : mettre en forme un texte, l'horodater, l'encadrer en HTML. Par héritage, chaque combinaison exigerait sa propre sous-classe — TexteHorodateEtEncadre, TexteMajusculeEtHorodate… une explosion combinatoire. Le Decorator résout ça en emballant.

interface Texte { public function rendu(): string; }

final class TexteBrut implements Texte
{
    public function __construct(private string $valeur) {}
    public function rendu(): string { return $this->valeur; }
}

// Un décorateur : même interface, enveloppe un Texte, ajoute sa touche.
final class Majuscules implements Texte
{
    public function __construct(private Texte $inner) {}
    public function rendu(): string { return strtoupper($this->inner->rendu()); }
}

final class Encadre implements Texte
{
    public function __construct(private Texte $inner) {}
    public function rendu(): string { return '[ ' . $this->inner->rendu() . ' ]'; }
}

// On empile : chaque couche enveloppe la précédente.
$t = new Encadre(new Majuscules(new TexteBrut('bonjour')));
$t->rendu();   // "[ BONJOUR ]"

Le simulateur te laisse activer les décorateurs un à un et voir la sortie se composer. Chaque couche transforme le résultat de la précédente — l'ordre d'empilement compte, exactement comme dans le code.

Observer : prévenir sans se connaître

Un objet change d'état, et d'autres doivent réagir — sans qu'il ait à les connaître un par un. L'Observer inverse le lien : ce sont les intéressés qui s'abonnent.

Une commande est payée. Il faut envoyer un e-mail de confirmation, mettre à jour le stock, notifier la comptabilité, déclencher la préparation. Si la classe Commande appelle elle-même ces quatre services, elle les connaît tous, dépend d'eux tous, et grossit à chaque nouveau besoin. C'est fragile et fermé au changement.

interface Observateur { public function surCommandePayee(Commande $c): void; }

final class Commande
{
    private array $observateurs = [];

    public function abonner(Observateur $o): void { $this->observateurs[] = $o; }

    public function payer(): void
    {
        // … logique de paiement …
        foreach ($this->observateurs as $o) {
            $o->surCommandePayee($this);   // on prévient, on ne fait pas à leur place
        }
    }
}

Ajouter un nouveau réagissant — un programme de fidélité, par exemple — ne touche plus à Commande : on écrit un nouvel observateur et on l'abonne. La commande reste close à la modification, ouverte à l'extension.

Command : transformer une action en objet

Emballer « ce qu'il faut faire » dans un objet ouvre des possibilités qu'un simple appel de méthode n'a pas : le mettre en file, le journaliser, le rejouer — et surtout, l'annuler.

Un appel de méthode, $editeur->ajouter('café'), s'exécute et disparaît. Impossible de le mettre de côté, de le passer à un worker, ou de l'annuler après coup. Le pattern Command transforme cette action en objet de première classe — et c'est ce qui débloque l'annulation.

interface Commande
{
    public function executer(): void;
    public function annuler(): void;   // la clé de l'undo
}

final class AjouterArticle implements Commande
{
    public function __construct(private Panier $panier, private string $article) {}
    public function executer(): void { $this->panier->ajouter($this->article); }
    public function annuler(): void  { $this->panier->retirer($this->article); }
}

Un « invocateur » garde une pile des commandes exécutées ; annuler, c'est dépiler la dernière et appeler son annuler(). Le simulateur ci-dessous met ça en scène : ajoute des articles, puis annule et refais. Chaque action est une commande empilée.

Adapter : faire parler deux interfaces incompatibles

Tu as un code qui attend une prise européenne et un appareil à fiche américaine. Tu ne réécris ni l'un ni l'autre : tu intercales un adaptateur. En logiciel, c'est exactement pareil.

Ton code métier attend une interface Logger avec une méthode log(string $message). La bibliothèque tierce que tu veux utiliser, elle, expose writeLine(array $data). Les deux sont incompatibles, et tu ne peux modifier ni ton métier ni la bibliothèque. L'Adapter est la pièce qui les réconcilie.

// Ce que ton code attend.
interface Logger { public function log(string $message): void; }

// L'adaptateur : implémente Logger, traduit vers la biblio tierce.
final class BiblioTierceAdapter implements Logger
{
    public function __construct(private BiblioTierce $biblio) {}

    public function log(string $message): void
    {
        // traduction de MON interface vers la SIENNE
        $this->biblio->writeLine(['msg' => $message, 'ts' => time()]);
    }
}

Le résultat : ton métier ne connaît que Logger, et rien de la bibliothèque tierce. Le jour où tu changes de bibliothèque, tu écris un nouvel adaptateur — le métier ne bouge pas d'un octet.

Tu fais déjà des patterns : Symfony en est tissé

Le meilleur moyen de comprendre un pattern, c'est de le reconnaître dans un outil que tu utilises tous les jours. Symfony est un catalogue vivant du Gang of Four.

Une fois qu'on a le vocabulaire, on ne peut plus le désapprendre : les patterns sont partout dans les frameworks que tu utilises. Symfony en particulier est un empilement lisible de ces solutions. Faire le tour, c'est ancrer chaque pattern dans du concret que tu manipules déjà.

Remarque aussi que ces patterns ne sont pas isolés : l'EventDispatcher (Observer) sert à implémenter des points d'extension, eux-mêmes souvent des Strategy ; le middleware (Chain of Responsibility) transporte des Command. Les patterns se combinent — un framework mûr, c'est une conversation entre eux.

Le revers : quand un pattern aggrave les choses

Le danger n'est pas d'ignorer les patterns, c'est d'en abuser. Un pattern posé sans problème à résoudre est de la complexité gratuite — et certains « patterns » sont carrément des pièges.

Apprendre les patterns crée une tentation redoutable : les appliquer partout, pour prouver qu'on les connaît. C'est le chemin le plus sûr vers un code plus difficile à lire que celui qu'on prétendait améliorer. Quelques garde-fous s'imposent.

Une manière saine de voir les choses : les patterns sont un vocabulaire de refactoring, pas un plan de construction. On écrit d'abord la solution la plus simple, on la laisse révéler ses tensions, et on introduit un pattern quand le code lui-même réclame cette structure. Le pattern nomme et cristallise une amélioration ; il ne la précède pas.

Synthèse : un vocabulaire au service du jugement

Les patterns ne remplacent pas le discernement — ils l'outillent. Voici comment choisir, et le réflexe à garder au-dessus de tous les autres.

On a parcouru les principes SOLID, puis six patterns concrets, avant de voir Symfony en être tissé et de mesurer le danger de l'excès. Récapitulons non pas des recettes, mais une façon de penser.

Les patterns vus, en une phrase chacun

Comment choisir

Où ça se relie