CONCLUSION

La pluie avait cessé. Le dernier dossier était classé. Sur l’écran, plus de lignes de code monstrueuses, plus de switch tentaculaires, plus de constructeurs à quinze paramètres. À la place, des noms : Strategy, Observer, Composite. Comme les pièces d’un dossier bien monté, chaque pattern avait sa place. Mais l’erreur serait de croire que l’enquête commence par choisir une pièce. Non. Elle commence par le problème. La trace de sang, le témoignage contradictoire, l’alibi trop parfait.

Penser en problèmes, pas en patterns

C’est la première et ultime leçon. Les Design Patterns ne sont pas une liste de solutions à coller sur du code. Ils sont une grille de lecture pour les problèmes récurrents.

• Vous avez un new partout qui vous lie à des classes concrètes ? C’est le problème de la création rigide. Regardez du côté des Créationnels.
• Vos classes se connaissent trop intimement, un changement en cascade tout ? C’est le problème du couplage fort. Les Structurels ont des outils pour ça.
• La logique métier est une soupe de if qui décide qui fait quoi ? C’est un problème de comportement distribué. Les Comportementaux organisent cela.

N’écrivez jamais class MaClasse extends Singleton. Écrivez votre code jusqu’à sentir la dette technique arriver. Puis, identifiez la pourriture spécifique (rigidité, fragilité, immobilité) et cherchez dans votre mémoire le pattern qui sent la même odeur.

Les patterns comme langage commun

C’est leur pouvoir caché, le plus précieux peut-être. Quand vous dites « On va mettre un Observer ici », ou « Ce service devrait être un Factory », vous ne décrivez pas juste une implémentation. Vous évoquez toute une intention, un risque connu, une solution éprouvée.

C’est un jargon, oui. Mais c’est le jargon des professionnels qui ont vu les mêmes crimes se reproduire. Cela permet de discuter architecture à un haut niveau d’abstraction, sans redescendre à chaque fois dans les détails d’implémentation. C’est un raccourci sémantique puissant.

L’expérience avant la recette

Le piège, c’est de voir les patterns comme des recettes de cuisine à appliquer bêtement. « Le livre dit qu’ici il faut un Decorator, donc je vais en mettre un. » C’est la voie royale vers la sur-ingénierie.

Les patterns sont le fruit de l’expérience. Ils émergent de la pratique, de la douleur du code qui pue. La vraie compétence n’est pas de connaître les 23 patterns par cœur. C’est d’avoir codé assez pour reconnaître le problème avant même de savoir qu’il a un nom. Alors, quand vous lisez Strategy, ça clique : « Ah, c’est ça que j’ai bricolé la fois dernière ! »

Construisez d’abord l’expérience. Codez. Faites des erreurs. Tombez dans le piège du couplage fort. Puis, lisez les patterns. Vous les comprendrez en profondeur, parce que vous aurez senti la douleur qu’ils soulagent.

Épilogue

Le bureau est vide maintenant. Les patterns sont rangés, comme les armes dans l’armurie. Ils ne sont ni bons ni mauvais en eux-mêmes. Ce n’est pas la faute du Singleton s’il est utilisé comme un état global maléfique. Ce n’est pas la faute du Visitor s’il rend le code illisible pour un simple besoin.

Ils sont des outils. Des clés pour des serrures récurrentes. Le bon artisan ne sort pas la clé la plus grosse ou la plus brillante. Il regarde la serrure. Il écoute le grincement. Il sent la résistance.

Puis il choisit.

Le polar noir du code continue. De nouveaux problèmes apparaîtront, des contraintes inédites (cloud, microservices, réactivité). De nouveaux patterns émergeront. Mais les principes fondamentaux – couplage, cohésion, encapsulation, abstraction –, eux, resteront.

Maintenant, sortez. Allez coder. Faites des erreurs. Et quand vous sentirez cette odeur familière de code qui tourne mal, souvenez-vous qu’il existe un nom pour ce malaise, et peut-être une façon de le canaliser.

L’enquête n’est jamais vraiment terminée.

FIN.