00 - Pourquoi les patterns comptent (et lesquels ignorer)
Ce que tu vas apprendre
- Pourquoi le livre du GoF ne suffit pas (et n'a jamais suffi)
- Quels design patterns on utilise vraiment en TypeScript backend
- Comment reconnaitre un pattern dans du code existant
Prerequisites
Aucun. Si tu sais écrire du TypeScript, tu es pret.
23 patterns. Tu en utiliseras 10.
En 1994, Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides ont publie "Design Patterns: Éléments of Reusable Object-Oriented Software". Le fameux livre du "Gang of Four". Vingt-trois patterns. Des schemas UML. Des exemples en C++ et Smalltalk.
Trente ans plus tard, les juniors continuent d'apprendre ces 23 patterns par coeur en formation. Et trente ans plus tard, j'en utilise une dizaine au quotidien. Les autres ? Soit ils ne s'appliquent pas a TypeScript, soit le langage les rend inutiles.
Abstract Factory dans un langage ou les fonctions sont des valeurs de première classe ? Inutile. Tu passes une fonction. Bridge pour séparer abstraction et implementation quand tu as des interfaces et du duck typing ? Overkill. Memento pour sauvegarder l'état quand JSON.parse(JSON.stringify(state)) existe ? Bon, celui-la c'est un peu reducteur, mais tu vois l'idee.
Un pattern, c'est quoi exactement ?
La définition que je donne a chaque promotion de CDA : un pattern est une solution recurrente a un problème recurrent dans un contexte donne. Trois mots comptent. Solution : c'est du concret, pas de la philosophie. Recurrente : si tu ne l'as rencontre qu'une fois, c'est pas un pattern, c'est un hack. Contexte : un pattern applique hors contexte, c'est un anti-pattern.
Un design pattern n'est pas un badge. Coller un Visitor sur un if/else avec deux branches, ca ne rend pas ton code plus pro. Ca le rend illisible. J'ai vu ca en revue de code chez un client l'an dernier. Un junior avait lu un article Medium sur les patterns et voulait tous les utiliser dans le meme sprint. Le Visitor Pattern pour dispatcher deux types de notifications. Quatre classes, une interface, un accept/visit. Le meme code tenait en 8 lignes avec un switch.
Les patterns de paltemps.fr (sans le savoir)
Sur paltemps.fr, on utilise plusieurs patterns sans les avoir nommes au depart. Les adaptateurs de recherche d'images (Unsplash, Pexels, Pixabay) ? C'est le pattern Adapter. Chaque service externe a une API différente, et on les traduit tous vers une interface commune ImageSearchPort. On n'a pas dit "tiens, implementons le pattern Adapter". On a dit "ces trois API renvoient des formats différents, on va normaliser". Le pattern etait la solution naturelle au problème.
La création de sessions IMAP avec chiffrement du mot de passe, TTL et pool de connexions ? C'est une Factory. Le système d'auto-tagging des flux RSS ? Ca ressemble a un Observer. Le repository de signatures qui lit et écrit dans un fichier JSON ? C'est... un Repository.
Les patterns emergent du code quand tu resous des problèmes réels. Les nommer apres coup aide a communiquer avec l'équipe. "Le truc qui créé les sessions IMAP" devient "la factory IMAP", et tout le monde comprend immédiatement la responsabilité de ce module.
Ce que cette serie couvre
Dix articles, dix concepts. Pas les 23 du GoF. Les patterns que tu vas croiser (ou devrait croiser) dans un projet TypeScript backend en 2026 :
- Factory : créer des objets sans
newpartout - Repository : abstraire l'acces aux donnees
- Strategy : changer de comportement a la volee
- Observer / EventEmitter : reagir aux changements
- Adapter : faire parler deux interfaces incompatibles
- Builder : construire des objets complexes pas a pas
- Decorator : ajouter des comportements sans modifier le code
- Singleton, Service Locator et DI : gerer les dépendances
- Anti-patterns : ce qu'il ne faut PAS faire
- Glossaire : tous les termes au meme endroit
Pour chaque pattern, tu auras : le problème qu'il resout, du code TypeScript complet et executable, un exemple tire de projets réels, et surtout quand ne pas l'utiliser. Parce que le vrai skill avec les design patterns, c'est de savoir quand s'en passer.
Un dernier mot avant de commencer
Si tu sors de cette serie en te disant "je vais mettre des patterns partout", j'aurai rate mon coup. L'objectif, c'est que tu reconnaisses les patterns dans le code que tu ecris deja, que tu saches quand un pattern va simplifier ton architecture, et que tu saches quand un if/else suffit.
Comme le dit Martin Fowler : "Any fool can write code that a computer can understand. Good programmers write code that humans can understand." Les patterns sont un outil de communication entre humains. Pas une fin en soi.
Article suivant : 01 - Factory : créer des objets sans new partout