Qu'est-ce qu'un design pattern ?
Un design pattern (patron de conception) est une solution eprouvee et réutilisable à un problème de conception recurrent en développement logiciel. Les design patterns ne sont pas du code prêt à l'emploi mais des modèles conceptuels adaptables. Ils ont été formalises par le "Gang of Four" (GoF) dans le livre "Design Patterns: Éléments of Reusable Object-Oriented Software" (1994) qui décrit 23 patterns classes en trois catégories.
Patterns créationnels
Les patterns créationnels gèrent la création d'objets. Singleton : garantit une instance unique d'une classe (controversee, souvent remplace par l'injection de dépendances). Factory Method : delegue la création à des sous-classes. Abstract Factory : cree des familles d'objets lies sans spécifier leurs classes concrètes. Builder : construit des objets complexes étape par étape (utile pour les objets avec de nombreux paramètres optionnels). Prototype : cree des objets en clonant un prototype existant.
Patterns structurels
Les patterns structurels organisent les relations entre objets. Adapter : convertit l'interface d'une classe en une autre attendue par le client. Decorator : ajoute dynamiquement des responsabilités à un objet sans modifier sa classe. Facade : fournit une interface simplifiée à un sous-systeme complexe. Proxy : contrôle l'accès à un objet (lazy loading, caching, sécurité). Composite : traite les objets individuels et les compositions uniformement (arbres).
Patterns comportementaux
Les patterns comportementaux gèrent la communication entre objets. Observer : notification automatique des dependants quand l'état change (event systems, réactive programming). Strategy : encapsule des algorithmes interchangeables. Command : encapsule une requête comme objet (undo/redo, file de commandes). Iterator : parcourt une collection sans exposer sa structure interne. State : modifie le comportement d'un objet quand son état change.
Patterns modernes et critiques
Au-delà du GoF, des patterns modernes ont emerge : Repository (abstraction de l'accès aux données), Dependency Injection (inversion du contrôle), CQRS (séparation lecture/écriture), Event Sourcing (historique d'événements). Les critiques des design patterns soulignent qu'ils compensent parfois les limitations du langage (les closures de JavaScript rendent le pattern Strategy trivial) et que leur usage excessif ajoute de la complexité inutile. Utilisez-les quand le problème qu'ils resolvent est réel, pas par anticipation.