Résumés des livres essentiels sur les Design Patterns

---

1. "Design Patterns: Elements of Reusable Object-Oriented Software" (GoF)

Auteurs : Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides Année : 1994 (réédité) Pages : 416

Résumé

C'est LE livre fondateur des Design Patterns. Les "Gang of Four" (GoF) ont catalogué 23 patterns classés en 3 catégories : création, structure, comportement.

Structure du livre

Partie 1 : Introduction aux patterns
- Qu'est-ce qu'un pattern ?
- Comment documenter un pattern
- Relations entre patterns
- Comment utiliser le catalogue

Partie 2 : Catalogue des 23 patterns
- Création (5) : Singleton, Factory Method, Abstract Factory,
  Builder, Prototype
- Structure (7) : Adapter, Bridge, Composite, Decorator,
  Facade, Flyweight, Proxy
- Comportement (11) : Chain of Resp., Command, Interpreter,
  Iterator, Mediator, Memento, Observer, State, Strategy,
  Template Method, Visitor

Partie 3 : Conclusion
- Applications
- Implémentations
- Bibliographie

Points clés

1. Principes réutilisables : Programmer vers une interface, pas une implémentation
2. Favoriser la composition sur l'héritage
3. Encapsuler ce qui varie - isole les parties changeantes
4. Format de pattern : Nom, Problème, Solution, Conséquences

Pertinence aujourd'hui (2020+)

• Les patterns restent valides, les implémentations ont évolué
• Certains patterns ont des équivalents modernes (ex: hooks remplacent certains GoF)
• Essentiel pour comprendre les patterns plus récents (architecturaux, cloud)

4 règles pour écrire des patterns (d'après GoF)

1. Encapsulez ce qui varie
2. Programmez vers une interface (abstraction)
3. Favorisez la composition sur l'héritage
4. Utilisez la délégation

---

2. "Patterns of Enterprise Application Architecture" (PoEAA)

Auteur : Martin Fowler Année : 2002 Pages : 560

Résumé

Fowler catalogue les patterns spécifiques aux applications d'entreprise : architecture n-tiers, ORM, web, distribution.

Patterns clés

Architecture:

• Layer (couches)
• MVC / Front Controller / Page Controller
• Service Layer / Application Facade

Domaine:

• Domain Model / Anemic Domain Model
• Unit of Work / Identity Map
• Repository / Data Mapper

Data Source:

• Table Data Gateway / Row Data Gateway
• Active Record / Data Mapper

Distribution:

• Remote Facade / Data Transfer Object (DTO)
• Service Stub / Registry

Points clés

1. Architecture en couches : Presentation → Domain → Data Source
2. Patterns de mapping objet-relationnel : Fondations des ORMs modernes
3. Patterns transactionnels : Unit of Work, Identity Map

Pertinence aujourd'hui

• Les patterns ORM sont implémentés dans tous les frameworks
• Le Service Layer est la base des microservices
• DTO/Remote Facade toujours utilisés dans les APIs REST

---

3. "Clean Architecture: A Craftsman's Guide to Software Structure and Design"

Auteur : Robert C. Martin (Uncle Bob) Année : 2017 Pages : 432

Résumé

Uncle Bob propose une approche architecturale centrée sur les principes SOLID et le Domain-Driven Design, avec l'indépendance des frameworks comme objectif principal.

Structure

Partie 1 : Paradigmes
- Programmation structurée
- Programmation orientée objet
- Programmation fonctionnelle

Partie 2 : SOLID
- SRP, OCP, LSP, ISP, DIP

Partie 3 : Principes des composants
- REP, CCP, CRP (cohésion)
- ADP, SDP, SAP (couplage)

Partie 4 : Architecture
- The Clean Architecture
- Indépendance des frameworks
- Cas d'usage

Partie 5 : Détails
- Bases de données, web, frameworks
- Tests
- Découplage

Clean Architecture (schéma conceptuel)

[Controllers] [Gateways] [Presenters]
        ↓           ↓           ↓
    [Use Cases (Interactors)]
        ↓           ↓           ↓
[Entities] [Repository Interfaces]
        ↓
[Databases, APIs, UI, Frameworks]

Règle de dépendance

Les dépendances vont de l'extérieur vers l'intérieur. Le code du domaine (Entities) ne dépend de rien.

Points clés

1. Les frameworks sont des détails, pas le cœur de l'architecture
2. Le code source doit être indépendant des frameworks, DB, UI
3. Les cas d'utilisation (use cases) sont le cœur de l'application
4. Le principe de dépendance inversé (DIP) est fondamental

Pertinence aujourd'hui

• Standard pour les architectures modernes en TypeScript/Java
• Base des architectures hexagonales et onion
• Fondation du Domain-Driven Design en pratique

---

4. "Head First Design Patterns"

Auteurs : Eric Freeman, Elisabeth Robson Année : 2004 (2nd edition 2021) Pages : 694

Résumé

Approche pédagogique unique avec visuels, exercices, et dialogues. Basé sur les 23 patterns GoF mais expliqués dans un style accessible.

Points forts

1. Style visuel : Diagrams, photos, comics
2. Exercices interactifs : "Match the pattern", "Fill in the blanks"
3. Ancrage mémoire : Répétitions, associations
4. Exemples en Java (2nd edition actualisée)

Patterns couverts (2nd edition)

• Strategy, Observer, Decorator, Factory, Singleton, Command
• Adapter, Facade, Template Method, Iterator, Composite
• State, Proxy, Compound patterns (MVC)

Chapitres bonus

• Pattern MVC comme métapattern
• Patterns et principes orientés objet (OO Basics, OO Principles)
• Anti-patterns

Pour qui ?

• Développeurs débutants en patterns
• Ceux qui veulent une approche moins académique
• Formateurs et enseignants

---

5. "Refactoring: Improving the Design of Existing Code"

Auteur : Martin Fowler Année : 1999 (2nd edition 2018) Pages : 448

Résumé

Le livre de référence sur le refactoring : améliorer le code existant sans changer son comportement externe.

Structure (2nd edition)

Partie 1 : Principes du refactoring
- Qu'est-ce que le refactoring ?
- Pourquoi refactorer ?
- Quand refactorer ?

Partie 2 : Catalogue des refactorings
- 60+ refactorings avec :
  - Motivation
  - Mécanique (étapes)
  - Exemples

Partie 3 : Techniques avancées
- Refactoring vers les patterns
- Refactoring et tests
- Refactoring large scale

Refactorings clés

Points clés

1. Refactoring sans tests, c'est du parachute sans toile : les tests sont indispensables
2. Le principe du "boyscout rule" : laisser le code plus propre qu'on ne l'a trouvé
3. Les refactorings vers les patterns : lien direct entre refactoring et Design Patterns

Pertinence aujourd'hui

• Essentiel pour la maintenance de code legacy
• Les refactorings sont implémentés dans les IDEs (IntelliJ, VS Code)
• Complémentaire aux Design Patterns : les patterns sont la destination, le refactoring est le chemin

---

6. "Domain-Driven Design: Tackling Complexity in the Heart of Software"

Auteur : Eric Evans Année : 2003 Pages : 560

Résumé

Le DDD est une approche de conception où le modèle de domaine est le cœur de l'architecture. Le livre présente des patterns pour modéliser des domaines complexes.

Patterns DDD

Stratégiques:

• Bounded Context : Limites explicites d'un modèle
• Ubiquitous Language : Langage partagé entre devs et métier
• Context Map : Relations entre contextes

Tactiques:

• Entity : Objet avec identité
• Value Object : Objet sans identité (immuable)
• Aggregate : Groupe d'objets avec racine
• Repository : Accès aux aggregates
• Domain Event : Événements du domaine
• Domain Service : Logique sans état
• Factory : Création d'objets complexes

Points clés

1. Le modèle est le cœur : pas la technique, mais la modélisation du métier
2. Ubiquitous Language : même langage dans le code et les discussions métier
3. Bounded Contexts : chaque contexte a son propre modèle
4. Aggregates : garanties de cohérence transactionnelle

Pertinence aujourd'hui

• Base des microservices (bounded context = service)
• Complémentaire à Clean Architecture
• Standard pour les applications complexes

---

Tableau comparatif

Parcours de lecture recommandé

1. Débutant : Head First Design Patterns
2. Intermédiaire : Clean Architecture
3. Expérimenté : GoF + Refactoring
4. Expert : PoEAA + DDD