Design patterns

Introduction

Les design patterns (ou motifs de conception) constituent le vocabulaire fondamental de l’architecte, ils procèdent de l’évolution des méthodes de conception logicielle des premières heures jusqu’à ce jour ; à ce titre, on ne peut éluder le sujet. Ne pas les connaître reviendrait à ignorer la perspective pour un peintre.

Ce chapitre est particulièrement dense, car il présente une grande quantité d’informations à un haut niveau d’abstraction. De plus, c’est un sujet qui mériterait plusieurs milliers de pages pour être traité en profondeur. Le lecteur consciencieux sera donc invité à consulter l’abondante bibliographie disponible sur le sujet pour approfondir les notions.

1. Genèse

Historiquement, celui qui, le premier, a introduit la théorie des patrons de conception (ou types culturels) est l’architecte Christopher Alexander dans sa passionnante réflexion, parue dans les années 70, autour du « Pattern Language » ; ouvrage dans lequel il explique en quoi la création individuelle - quel qu’en soit le domaine d’application - se rapproche inéluctablement d’un idéal collectif qu’on peut identifier à travers ses motifs répétitifs et qui constitue une forme d’émergence...

Patterns

Voici un schéma illustrant les relations entre les patterns du GOF :

Figure 13.1 : Relations entre les design patterns

1. Création

Les formes de création ont pour vocation d’abstraire le processus d’instanciation, de rendre indépendante la façon dont les objets sont créés, composés, assemblés et représentés et d’encapsuler la connaissance de la classe concrète qui instancie. Autrement dit, on voudra cacher ce qui est créé, qui crée, comment et quand.

Parmi ces patterns définis par le GOF, nous trouverons :

Abstract Factory pour instancier une famille d’objets.
Builder pour déterminer la classe de l’objet à instancier suivant son contenu.
Factory Method pour instancier un objet dont on ne connaît pas la classe.
Prototype pour instancier des objets par clonage.
Singleton pour garantir l’unicité d’un objet.

a. Abstract Factory

Ce modèle fournit une interface pour créer des familles d’objets liés ou dépendants sans spécifier leurs classes concrètes.

Problème

Un système doit être indépendant de la façon dont ses produits sont créés, assemblés et représentés.
Un système repose sur un produit d’une famille de produits.
On veut définir une interface unique à une famille de produits concrets.

Solution

On fournit une interface pour créer des objets d’une même famille sans préciser leurs classes concrètes.

Figure 13.2 : Abstract Factory

AbstractFactory définit l’interface des méthodes de création. Dans le diagramme, il n’y a qu’une méthode de création pour un objet d’une classe. Mais le diagramme sous-entend un nombre indéfini de méthodes pour un nombre indéfini de classes.
ConcreteFactory1 et ConcreteFactory2 implémentent l’interface et instancient la classe concrète appropriée.
AbstractProductA et AbstractProductB définissent l’interface d’un type d’objet instancié.
ProductA1, ProductA2 et ProductB1, ProductB2 sont des sous-classes concrètes d’AbstractProductA et d’AbstractProductB. Elles sont instanciées par les ConcreteFactory...