Pourquoi les design patterns

Le problème

En développement, les mêmes problèmes de conception reviennent constamment : gérer des dépendances entre objets, rendre du code extensible sans le réécrire, organiser la communication entre composants.

Ces problèmes ne sont pas nouveaux. En 1994, Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides, le Gang of Four (GoF), publient Design Patterns: Elements of Reusable Object-Oriented Software. Ils y cataloguent 23 patterns pour résoudre des problèmes récurrents en conception orientée objet.

Ce qu'est un pattern

Un pattern, ce n'est pas du code. C'est une solution réutilisable à un problème récurrent dans un contexte donné. C'est un vocabulaire commun entre développeurs.

Dire "on va utiliser un Decorator ici" est plus précis que "on va envelopper cette fonction pour lui ajouter du comportement". Le pattern nomme le concept, pas l'implémentation.

Classification GoF

Les 23 patterns GoF sont répartis en trois catégories :

Créationnels: gèrent la création d'objets

• Singleton, Factory Method, Abstract Factory, Builder, Prototype

Structurels: gèrent la composition d'objets et de classes

• Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy

Comportementaux: gèrent la communication entre objets

• Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor

En 2026

Le livre GoF visait la programmation orientée objet en C++ et Smalltalk. Certains patterns sont devenus natifs dans les langages modernes (Iterator en TypeScript/JS avec Symbol.iterator), d'autres ont évolué (le Singleton en module ES).

Ce cours couvre les patterns GoF les plus utiles en TypeScript, puis des patterns spécifiques au front-end (Repository, Flux, Compound Components) qui ne figurent pas dans le livre original mais répondent aux mêmes principes.

Ce que ce cours n'est pas

Les patterns ne sont pas des solutions universelles. Un pattern mal appliqué ajoute de la complexité sans bénéfice. L'objectif est de reconnaître les situations où un pattern est pertinent pas de les plaquer partout.

// Anti-pattern : Singleton pour tout et n'importe quoi
class UserNameFormatter {
  private static instance: UserNameFormatter;
  static getInstance() { ... }
  format(name: string) { return name.toUpperCase(); }
}

// Ce n'est pas un problème de création d'objet.
// C'est juste une fonction pure.
function formatUserName(name: string) {
  return name.toUpperCase();
}

Reconnaître qu'un pattern n'est pas nécessaire est aussi important que savoir l'appliquer.