Head First Design Patterns

1On ne réutilise pas du code, on réutilise de l'expérience

C'est la promesse du livre, posée dès le chapitre 1 : « avec les patterns, on ne réutilise pas du code, on réutilise de l'expérience » (ch. 1). Un pattern n'est pas une bibliothèque à installer : c'est « une solution à un problème dans un contexte » (ch. 13), un piège que des milliers d'équipes ont rencontré avant vous, et la sortie qu'elles ont fini par trouver. Et la vraie valeur n'est pas où l'on croit : « ne sous-estimez pas le pouvoir d'un vocabulaire partagé » (ch. 13). Dire « mets un Observer là-dessus » en réunion remplace dix minutes d'explications. Un pattern, c'est d'abord un mot.

2Encapsulez ce qui varie (l'histoire des canards en caoutchouc volants)

Le chapitre 1 raconte l'histoire de Joe, développeur du jeu SimUDuck. Ses chefs veulent que les canards volent. Joe ajoute fly() dans la classe mère Duck… et les canards en caoutchouc se mettent à voler aussi : « une mise à jour locale du code a causé un effet de bord non local (des canards en caoutchouc volants !) » (ch. 1). La leçon fondatrice du livre : « identifiez ce qui varie dans votre application et séparez-le de ce qui ne change pas » (ch. 1). Voler, cancaner : ça varie selon le canard, donc on le sort de la classe et on le branche comme un composant interchangeable. Le livre l'affirme : ce principe « forme la base de presque tous les patterns » (ch. 1).

3Préférez la composition à l'héritage (le cauchemar Starbuzz)

Starbuzz Coffee a une classe par boisson. Ajoutez les suppléments (lait, soja, mocha, chantilly) et ça donne une sous-classe par combinaison : MochaSojaChantilly, DoubleMochaLait… l'explosion. La solution du Decorator : une boisson de base qu'on emballe dans des poupées russes de suppléments, chacune ajoutant son prix et sa description en déléguant à la suivante. Et le livre démine la confusion classique : oui, le décorateur hérite de Boisson, « mais on utilise l'héritage pour obtenir le bon type, pas pour hériter du comportement ; le comportement vient de la composition » (ch. 3). L'héritage fige tout à la compilation ; la composition se rebranche à l'exécution.

4Quand vous voyez new, pensez « béton »

La pizzeria d'Objectville : un orderPizza() plein de if (type == "fromage") new PizzaFromage(). Chaque nouvelle pizza, chaque franchise (New York, Chicago) oblige à rouvrir ce code. La règle mnémotechnique du livre : « quand vous voyez new, pensez concret » (ch. 4), c'est-à-dire couplé en dur à une classe précise. Les patterns Factory déplacent la création dans un endroit dédié, et le principe derrière : « dépendez d'abstractions, pas de classes concrètes » (ch. 4). Avec une honnêteté rare : après avoir énoncé ses trois règles strictes, le livre avoue que « clairement, le moindre programme Java jamais écrit les viole toutes » (ch. 4). Ce sont des boussoles, pas des lois.

// ✗ Avant : la création est mélangée à la recette
Pizza orderPizza(String type) {
    if (type == "cheese")     pizza = new CheesePizza();   // ← change à chaque
    else if (type == "clam") pizza = new ClamPizza();     //   nouvelle pizza
    pizza.prepare(); pizza.bake(); pizza.cut(); pizza.box();  // ← ne change jamais
}

// ✓ Après : la partie qui varie est déléguée à la fabrique
Pizza orderPizza(String type) {
    pizza = factory.createPizza(type);  // le seul endroit qui connaît les classes
    pizza.prepare(); pizza.bake(); pizza.cut(); pizza.box();
}

La recette (préparer, cuire, couper, emballer) ne bouge plus jamais. Ajouter la pizza du mois ne rouvre qu'un seul fichier : la fabrique.

5La serveuse ne sait pas ce qu'il y a sur le bon (Command et le découplage)

Comment une télécommande domotique peut-elle piloter une lampe, un jacuzzi et une chaîne hi-fi sans connaître leurs détails ? Le livre répond par le restaurant : le client écrit sa commande, la serveuse la transporte sans la lire, le cuisinier l'exécute. Le bon de commande, c'est le pattern Command : une demande emballée dans un objet, qu'on peut stocker, mettre en file d'attente, annuler. Le même esprit donne le principe d'Hollywood du chapitre 8 : « ne nous appelez pas, on vous appellera » (ch. 8), le composant de haut niveau décide quand appeler les détails, jamais l'inverse. C'est le squelette de tous les frameworks que vous utilisez.

6Le MVC n'est pas un bloc, c'est trois patterns assemblés

D'abord, ce que MVC veut dire quand on développe : trois boîtes aux rôles séparés. Le Modèle, c'est les données et leurs règles (le panier d'une boutique et son total). La Vue, c'est ce qui s'affiche (la page du panier). Le Contrôleur, c'est ce qui reçoit vos actions (le clic sur « Ajouter »). Le tour complet : vous cliquez sur « Ajouter au panier », le contrôleur reçoit le clic et demande au modèle d'ajouter l'article, le modèle change, recalcule le total et prévient, la vue se redessine avec le panier à jour.

Ce que le chapitre 12 révèle : « le MVC est un pattern composé, constitué des patterns Observer, Strategy et Composite » (ch. 12). Autrement dit, chaque liaison de ce tour est un pattern que le livre a déjà enseigné.

• La liaison Modèle → Vue, c'est Observer (l'abonnement). Le panier ne connaît pas la page qui l'affiche. Il tient une liste d'abonnés et leur crie « j'ai changé ». C'est pour ça qu'on peut ajouter un deuxième affichage (le petit compteur d'articles en haut à droite) sans toucher une ligne au panier : le compteur s'abonne, c'est tout.
• La liaison Vue → Contrôleur, c'est Strategy (le comportement branché). La page ne sait pas quoi faire d'un clic : elle le transmet à son contrôleur, une pièce branchée qu'on peut remplacer (les canards de l'idée 2). Même page, comportement interchangeable : en mode démo, on branche un contrôleur qui n'enregistre rien.
• La structure de la Vue, c'est Composite (l'arbre). La page contient des panneaux qui contiennent des boutons. Dire « redessine-toi » à la page redessine tout l'arbre, sans se demander qui est un groupe et qui est une feuille.

Précision pour les devs web, parce que ce tour avec notification peut surprendre : c'est le MVC d'origine, celui des interfaces de bureau, et il survit aujourd'hui dans les frontends réactifs (Vue, React), où les composants s'abonnent à l'état. Côté serveur (Symfony, Laravel), HTTP aplatit le tour : à chaque requête, le contrôleur interroge le modèle et passe lui-même le résultat à la vue, puis tout disparaît. La liaison Observer n'a pas le temps d'exister. Le livre couvre cette variante web sous le nom « Model 2 » (ch. 12) : mêmes rôles, mais le facteur ne sonne qu'une fois.

La récompense de ce découpage reste la même dans les deux variantes : chaque pièce se remplace sans toucher aux deux autres. Et une fois qu'on a vu ça, les frameworks cessent d'être de la magie : ce sont des assemblages de pièces qu'on connaît.

7Le Singleton, ou le pattern qui vient avec sa notice de danger

Le Singleton garantit une instance unique. L'histoire du livre : la chaudière à chocolat industrielle, où deux instances simultanées finissent en 500 gallons de mélange par terre. C'est le pattern le plus simple du catalogue, et le livre passe la moitié du chapitre sur ses pièges : deux threads peuvent créer deux instances en même temps, et la correction naïve (tout synchroniser) « peut dégrader les performances d'un facteur 100 » (ch. 5). Sa conclusion : « les Singletons sont faits pour être utilisés avec parcimonie » ; si votre application en est pleine, « regardez votre design d'un œil critique » (ch. 5). Un livre de patterns qui vous apprend à vous méfier d'un pattern, c'est exactement le bon état d'esprit.

8Le meilleur chapitre explique quand NE PAS utiliser de pattern

Le chapitre 13 est un antidote au livre lui-même. La règle d'or : « utilisez toujours la solution la plus simple qui répond au besoin, même si elle n'inclut aucun pattern » (ch. 13). L'avertissement, en toutes lettres : « l'abus de design patterns mène à du code carrément sur-ingéniéré » (ch. 13). Et la progression : le débutant veut « un pattern pour Hello World », l'intermédiaire en met partout, l'esprit zen les voit naturellement et cherche d'abord la simplicité. Même l'autocritique est là : sur leur propre simulateur de canards à six patterns, les auteurs reconnaissent que « certains de ces patterns étaient largement excessifs » (ch. 12).