Aller au contenu

Les Design Patterns

Présentation

Après avoir présenté les cinq principes SOLID, qui constituent des bonnes pratiques de conception, nous allons maintenant nous intéresser aux Design Patterns.

Les Design Patterns, tels que nous les connaissons aujourd'hui dans le développement logiciel, ont été popularisés par les travaux de quatre auteurs surnommés le Gang of Four (GoF) : Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides. En 1994, ils publient l'ouvrage de référence Design Patterns: Elements of Reusable Object-Oriented Software, dans lequel ils décrivent 23 modèles de conception, destinés à résoudre des problèmes récurrents de conception orientée objet. Ces modèles ne constituent pas des solutions à copier tel qu'ils sont présentés dans les articles, mais des solutions éprouvées permettant de concevoir des applications plus souples, plus maintenables et plus évolutives.

Au cours des prochains jours, je publierai une série d'articles consacrés à plusieurs de ces Design Patterns. Pour chacun d'eux, je présenterai le problème auquel il répond, son principe de fonctionnement, un diagramme de classes UML ainsi qu'un exemple complet d'implémentation en C#.

Les 23 Design Patterns sont répartis en trois familles, selon la nature du problème qu'ils cherchent à résoudre : la création des objets, leur organisation et leur comportement.

Relations entre les principes SOLID et les Design Patterns

De nombreux Design Patterns favorisent l'application des principes SOLID :

  • SRP (Single Responsibility Principle) : Builder, Facade, Command, State.

  • OCP (Open / Close Principle) : Strategy, Factory Method, Abstract Factory, Adapter, Decorator, Observer, Command, State, Template Method.

  • LSP (Liskov Substitution Principle) : Strategy, Decorator, Template Method.

  • ISP (Interface Segregation Principle) : Facade.

  • DIP (Dependency Inversion Principle) : Factory Method, Abstract Factory, Observer.

Les Design Patterns de création

Les Design Patterns de création concernent les mécanismes de création d'objets. Leur objectif est de rendre l'instanciation des classes plus flexible, en limitant les dépendances. Ainsi, ils permettent ainsi de faire évoluer plus facilement une application, tout en respectant les principes de conception orientée objet :

  • Factory Method : délègue la création d'un objet à une méthode spécialisée, afin de laisser les classes dérivées choisir l'implémentation pour instancier.

  • Abstract Factory : fournit une interface permettant de créer des ensembles d'objets liés ou compatibles, sans connaître leurs classes ayant permis de les instancier.

  • Builder : sépare la construction d'un objet complexe de sa représentation, afin de créer différentes variantes à partir du même processus de construction.

  • Prototype : crée de nouveaux objets en clonant une instance existante plutôt qu'en appelant un constructeur.

  • Singleton : garantit qu'une classe n'est instanciée qu'une seule fois, tout en fournissant un point d'accès global à cette instance.

Les Design Patterns structurels

Les Design Patterns structurels décrivent la manière d'organiser les classes et les objets, afin de construire des structures plus complexes. Ils permettent de faciliter la réutilisation du code, réduire le couplage entre les composants et simplifier l'évolution de l'architecture :

  • Adapter : permet à deux interfaces incompatibles de collaborer en adaptant l'une à l'autre.

  • Bridge : sépare une abstraction de son implémentation afin qu'elles puissent évoluer de manière indépendante.

  • Composite : organise des objets sous forme d'arborescence, afin de manipuler de manière uniforme les objets simples et les compositions d'objets.

  • Decorator : ajoute dynamiquement de nouvelles responsabilités à un objet sans modifier son implémentation.

  • Facade : fournit une interface simplifiée pour accéder à un ensemble de classes ou à un sous-système complexe.

  • Flyweight : réduit l'encombrement de la mémoire en partageant les parties communes entre de nombreux objets similaires.

  • Proxy : introduit un objet intermédiaire qui contrôle ou enrichit l'accès à un autre objet.

Les Design Patterns comportementaux

Les Design Patterns comportementaux concernent les échanges entre les classes et à la répartition des responsabilités. Ils facilitent la communication entre les composants et permettent de faire évoluer leurs comportements tout en limitant leur couplage (favorisant le couplage faible) :

  • Chain of Responsibility : fait circuler une requête entre plusieurs objets jusqu'à ce que l'un d'entre eux soit capable de la traiter.

  • Command : encapsule une action dans un objet afin de la transmettre, la stocker ou l'exécuter ultérieurement.

  • Interpreter : définit une représentation d'une grammaire et un mécanisme permettant d'interpréter des expressions qui la respectent.

  • Iterator : permet de parcourir les éléments d'une collection, sans connaître la manière dont ils sont stockés ou organisés.

  • Mediator : centralise les échanges entre plusieurs objets afin de réduire leurs dépendances directes.

  • Memento : capture et restaure l'état interne d'un objet sans exposer ses détails d'implémentation.

  • Observer : établit une relation de dépendance entre des objets, afin que les observateurs soient automatiquement informés des changements d'état.

  • State : modifie dynamiquement le comportement d'un objet en fonction de son état interne.

  • Strategy : encapsule plusieurs algorithmes interchangeables et permet de choisir dynamiquement celui à exécuter.

  • Template Method : définit le squelette d'un algorithme, tout en laissant certaines étapes être redéfinies par les classes dérivées.

  • Visitor : sépare les traitements de la structure des objets, afin d'ajouter de nouveaux comportements sans modifier les classes existantes.

Informations sur le contenu des Design Patterns

Dans chacun des chapitres concernant les Design Patterns, le "code client" correspond au code utilisant les classes du design pattern.