Les design patterns aussi appelés « patrons de conception » en français, répondent à des problèmes communs de conception. Des problèmes auxquels on a tous eu à faire un jour ou l’autre en programmation orientée objet.

Elles ont toutes été introduite en 1995 par le livre « Desgin Pattern – Elements of Reusable Object Oriented Software » du Gang of Four (le « Gang des quatres » constitué de Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides).

Ces solutions de conception ne sont pas forcément les plus adaptées, étant donné que chaque code est unique et que chaque implémentation est spécialisée. Elles n’offrent que des solutions à des sujets fréquents. Mais elles restent malgré tout des références à connaître et à maîtriser pour tout bon développeur qui se respecte.

Les patrons offrent la possibilité de capitaliser un savoir précieux né du savoir-faire d’experts

— Buschmann, 1996

Les 23 design patterns du GoF

Ces patrons de conceptions sont au nombre de 23, du moins ceux introduits par le Gang of Four. Ils sont subdivisé en 3 familles : construction, structuraux et comportementaux. Chaque famille répond à un type de problème connu.

Vous trouverez ci-dessous une liste exhaustive de ces design patterns avec pour chacun, une brève description et le lien de la page Wikipédia correspondante.

Design patterns de construction

Ils ont pour but d’abstraire le mécanisme de construction et d’instantiation d’objets.

  • Singleton : permet de s’assurer qu’une classe ne possède qu’une seule instance (voir l’article)
  • Abstract Factory : permet la création d’objets regroupés en familles sans devoir connaître les classes concrètes destinées à la création de ces objets
  • Factory Method : permet d’introduire une méthode abstraite de création d’un objet en reportant aux sous-classes concrètes la création effective
  • Builder : permet de séparer la construction d’objets complexes de leur implantation de sorte qu’un client puisse créer ces objets complexes avec des implantations différentes
  • Prototype : permet de créer de nouveaux objets par duplication d’objets existants appelés prototypes qui disposent de la capacité de clonage

Design patterns structuraux

Ils ont pour but de faciliter l’indépendance de l’interface d’un objet ou d’un ensemble d’objets par rapport à son implantation.

  • Adapter : permet de convertir l’interface d’une classe existante en l’interface attendue par les des clients également existants afin qu’ils puissent travailler ensemble
  • Bridge : permet de séparer l’aspect d’implantation d’un objet de son aspect de représentation et d’interface
  • Composite : permet de composer les objets dans les structures de type arbre ou arborescence
  • Decorator : permet d’ajouter dynamiquement des fonctionnalités supplémentaires à un objet
  • Façade : permet de simplifier l’accès à un ensemble d’objets formant un sous-système en fournissant à l’extérieur une interface unifiée
  • Flyweight : permet de partager des ressources en permettant la mise en oeuvre d’un grand nombre de petits objets
  • Proxy : permet de masquer la complexité d’utilisation d’un objet en présentant une interface simplifiée

Design patterns comportementaux

Ils ont pour but de fournir des solutions pour distribuer les traitements et les algorithmes entre les objets.

  • Chain of Responsibility : permet de construire une chaîne d’objets telle que si un objet de la chaîne ne peut pas répondre à une requête, il puisse la transmettre à son successeur et ainsi de suite jusqu’à ce que l’un des objets de chaîne y réponde
  • Command : permet d’encapsuler une requête sous forme d’objet
  • Iterator : permet d’accéder à des éléments d’un agrégat séquentiellement (exemple premier : parcourir et accéder aux éléments sans pour autant exposer sa structure interne)
  • Mediator : permet de construire un objet dont la vocation est la gestion et le contrôle des interactions dans un ensemble d’objets sans que ses éléments doivent se connaître mutuellement
  • Memento : permet de capturer et d’externaliser un objet interne de l’état de sorte que l’objet peut être remis dans cet état plus tard, sans violer l’encapsulation
  • Observer : permet de définir une relation 1-n entre les objets de sorte que quand un objet change d’état, tous les objets en relation notifiés et mis à jour automatiquement
  • State : permet, lorsqu’un objet est altéré, de changer son comportement
  • Strategy : permet ed définir une famille d’algorithmes, encapsulés les unes dans les autres, et de les rendre interchangeables
  • Template Method : permet de redéfinir certaines étapes d’un algorithme sans modifier la structure de l’algorithme.
  • Visitor : permet de définir une nouvelle  opération sans changer les classes des éléments sur lesquels il opère

Pour conclure

Toutes ces solutions conceptuelles apportent une manière « clé en main » de résoudre la plupart des problèmes liés à la conception en programmation orienté objet. Mais ce n’est les seules. En effet, d’autre design patterns existent et ont été introduit au fur et à mesure des problèmes communs rencontrés dans la conception : le pattern MVC (pour Model View Controller) pour ne citer que lui, et son petit frère le MVVM (pour Model View ViewModel) introduit par Microsoft.

Au bout du compte, il est important de connaître tous ces patrons de conception ou au moins d’en avoir une idée. Mais leur utilisation ne doit pas être une substitution à la mise en oeuvre d’une bonne conception.

Liste de lecture

Design Patterns: Elements of Reusable Object-Oriented Software de Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides

Head First Design Patterns de Elisabeth Freeman et Eric Freeman

Design Patterns pour C# de Laurent Debrauwer