Chapitre 0
Chapitre 00 — Introduction aux Design Patterns
Chapitre 00 — Introduction aux Design Patterns
Cours 00 — Introduction aux Design Patterns
1. Origine des Design Patterns
1.1 Christopher Alexander (architecte)
Le concept de pattern vient de l'architecture et de l'urbanisme. Christopher Alexander, architecte autrichien, publie en 1977 A Pattern Language : un catalogue de 253 patterns pour concevoir des villes, des quartiers, des bâtiments.
"Chaque pattern décrit un problème qui se produit de façon répétée dans notre environnement, puis décrit le cœur de la solution à ce problème, de telle sorte qu'on puisse utiliser cette solution des millions de fois sans jamais le faire deux fois de la même façon." — Christopher Alexander
1.2 Gang of Four (1994)
En 1994, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (les "Gang of Four" — GoF) publient Design Patterns: Elements of Reusable Object-Oriented Software. Cet ouvrage adapte le concept d'Alexander au génie logiciel et catalogue 23 patterns répartis en 3 catégories.
Diagramme en cours de génération...
1.3 Patterns modernes
Aujourd'hui, le catalogue s'est enrichi :
| Type | Exemples |
|---|---|
| Architecturaux | MVC, MVVM, Microservices, CQRS, Event Sourcing |
| Cloud | Circuit Breaker, Retry, Saga, Sidecar |
| Fonctionnels | Monade, Functor, Immutabilité |
| React/Vue | Hooks, Composants, Render Props, Provide/Inject |
2. Définition et vocabulaire
Un design pattern est une solution générale et réutilisable à un problème récurrent dans un contexte donné.
Structure d'un pattern (GoF)
- Nom — identifiant du pattern
- Problème — description du problème et son contexte
- Solution — description abstraite des éléments et leurs relations
- Conséquences — avantages et inconvénients
Éléments constitutifs
- Contexte — situation dans laquelle le problème se pose
- Force — contraintes qui s'exercent sur la solution
- Solution — arrangement d'éléments qui résout le problème
3. Les catégories de patterns
3.1 Patterns de création (5)
Ils abstraient le processus d'instanciation :
| Pattern | Objectif |
|---|---|
| Singleton | Une seule instance d'une classe |
| Factory Method | Déléguer la création aux sous-classes |
| Abstract Factory | Familles d'objets cohérents |
| Builder | Construction complexe étape par étape |
| Prototype | Clonage d'objets existants |
3.2 Patterns structuraux (7)
Ils composent des classes et objets pour former de plus grandes structures :
| Pattern | Objectif |
|---|---|
| Adapter | Rendre compatibles des interfaces incompatibles |
| Bridge | Séparer abstraction et implémentation |
| Composite | Traiter des objets individuels et des compositions uniformément |
| Decorator | Ajouter des responsabilités dynamiquement |
| Facade | Simplifier une interface complexe |
| Flyweight | Partager des données pour économiser la mémoire |
| Proxy | Contrôler l'accès à un objet |
3.3 Patterns comportementaux (11)
Ils gèrent les algorithmes et les responsabilités entre objets :
| Pattern | Objectif |
|---|---|
| Chain of Responsibility | Chaîner des handlers |
| Command | Encapsuler une requête en objet |
| Interpreter | Interpréter un langage |
| Iterator | Parcourir une collection |
| Mediator | Centraliser les communications |
| Memento | Capturer/restaurer l'état |
| Observer | Notifier des changements |
| State | Changer le comportement selon l'état |
| Strategy | Encapsuler des algorithmes interchangeables |
| Template Method | Définir le squelette d'un algorithme |
| Visitor | Séparer algorithme et structure |
3.4 Patterns architecturaux
- Layered Architecture (n-tiers)
- MVC / MVP / MVVM
- Hexagonal Architecture (Ports & Adapters)
- Microservices
- Event-Driven Architecture
- CQRS (Command Query Responsibility Segregation)
- Event Sourcing
4. Pourquoi utiliser des patterns ?
Avantages
- Vocabulaire commun : "utilisons un Adapter" est plus court qu'une explication de 10 minutes
- Solutions éprouvées : validées par des années de pratique
- Réutilisabilité : applicables dans de nombreux contextes
- Maintenabilité : code mieux structuré, plus facile à faire évoluer
- Documentation : les patterns documentent l'architecture
Quand les utiliser ?
- Un problème revient fréquemment
- Vous cherchez à rendre le code plus flexible
- Vous voulez communiquer la structure à votre équipe
- Vous refactorez un code existant
Quand NE PAS les utiliser ?
- Solution simple suffit (KISS)
- Le pattern ajoute de la complexité inutile (YAGNI)
- Vous ne maîtrisez pas encore bien le pattern
5. Anti-patterns
Un anti-pattern est une solution qui semble bonne mais qui cause plus de problèmes qu'elle n'en résout.
Anti-patterns classiques
| Anti-pattern | Description |
|---|---|
| God Class | Une classe qui fait tout |
| Spaghetti Code | Code sans structure, plein de goto/break |
| Golden Hammer | Utiliser le même pattern partout |
| Copy-Paste | Duplication de code |
| Premature Optimization | Optimiser avant d'avoir mesuré |
| Singletonitis | Abus du Singleton (état global caché) |
| Magic Numbers | Constantes littérales non nommées |
Diagramme en cours de génération...
6. UML essentiel pour les patterns
6.1 Diagramme de classes
Diagramme en cours de génération...
6.2 Relations UML
| Relation | Notation | Signification |
|---|---|---|
| Héritage | ▷— | "est un" |
| Implémentation | ▷- - | "implémente" |
| Association | —— | "a un" |
| Agrégation | ◇— | "a un" (partie autonome) |
| Composition | ◆— | "a un" (partie non autonome) |
| Dépendance | - -> | "utilise temporairement" |
6.3 Diagramme de séquence
Diagramme en cours de génération...
7. Critiques des patterns
Over-engineering
- Imposer des patterns là où une simple fonction suffit
- "Design Pattern Driven Development" — on cherche à utiliser des patterns plutôt qu'à résoudre des problèmes
"Pattern blindness"
On force un problème à entrer dans un pattern existant au lieu de chercher la solution naturelle.
"A pattern language" vs catalogue rigide
Les patterns devraient être un langage, pas une checklist.
Opinion de Peter Norvig
"Les design patterns sont des omissions du langage" — si un langage supporte nativement une fonctionnalité (ex: closures remplacent Strategy dans certains cas), le pattern devient invisible.
Quand les patterns sont-ils nuisibles ?
- Quand ils masquent un mauvais design
- Quand ils ajoutent des couches d'indirection sans bénéfice
- Quand l'équipe ne les maîtrise pas
- Quand le code n'évoluera jamais
8. Comment choisir un pattern ?
Analyse du problème
Diagramme en cours de génération...
Checklist de sélection
- Comprendre le problème dans son contexte réel
- Identifier les forces/contraintes en présence
- Rechercher le pattern qui équilibre ces forces
- Évaluer les conséquences du choix
- Prototyper pour valider l'adéquation
- Itérer — le choix n'est pas définitif
Pièges à éviter
- Choisir un pattern "parce qu'il est connu"
- Combiner trop de patterns (Pattern Overdose)
- Ignorer les alternatives idiomatiques du langage
- Négliger l'impact sur la testabilité
Résumé
- Un design pattern est une solution éprouvée à un problème récurrent
- Les 23 patterns GoF sont la base, mais il existe des patterns modernes (architecturaux, cloud, fonctionnels)
- Les patterns se classent en création, structural, comportemental
- Un anti-pattern est une mauvaise solution qui semble bonne
- L'UML aide à visualiser et communiquer les patterns
- Attention au sur-engineering — un pattern doit résoudre un problème, pas en créer
- Le bon pattern dépend du contexte et des forces en présence