Patron de conception

Pour les articles homonymes, voir Patron.

le patron Proxy

En informatique, et plus particulièrement en développement logiciel, un patron de conception (en anglais : « design pattern ») est un arrangement caractéristique de modules, reconnu comme bonne pratique en réponse à un problème de conception d'un logiciel. Il décrit une solution standard, utilisable dans la conception de différents logiciels^[1].

Un patron de conception est issu de l'expérience des concepteurs de logiciels^[2]. Il décrit sous forme de diagrammes un arrangement récurrent de rôles et d'actions joués par des modules d'un logiciel, et le nom du patron sert de vocabulaire commun entre le concepteur et le programmeur^[3]. D'une manière analogue à un patron de couture, le patron de conception décrit les grandes lignes d'une solution, qui peuvent ensuite être modifiées et adaptées en fonction des besoins^[4].

Les patrons de conception décrivent des procédés de conception généraux et permettent en conséquence de capitaliser l'expérience appliquée à la conception de logiciel. Ils ont une influence sur l'architecture logicielle d'un système informatique.

Les types de patrons

Les patrons de conception ne sont ni des patrons d'architecture ni des idiotismes de programmation.

• Le patron d'architecture apporte des solutions sur la manière de concevoir l'organisation à grande échelle (architecture) d'un logiciel en faisant abstraction des détails. Il concerne la structure générale d'un logiciel, sa subdivision en unités plus petites, comporte des guides de bonne pratiques et des règles générales qui ne peuvent pas être traduites directement en code source^[5].

• Le patron de conception suggère un arrangement, une manière d'organiser des modules ou des classes. Il décrit une organisation de classes fréquemment utilisée pour résoudre un problème récurrent. Le patron de conception parle d'instances, de rôles et de collaboration^[5].

• l'idiotisme de programmation est une construction spécifique à un langage de programmation, qui décrit une manière fréquente de mettre en œuvre une solution à un problème, dans le langage de programmation en question. Par exemple pour effectuer 100 fois une opération, un programmeur en langage C utilisera un code contenant la phrase for (i = 0; i < 100; i++). L'utilisation d'un idiotisme par le programmeur lui évite d'avoir à remettre en question la structure détaillée du programme et améliore la qualité du produit^[5].

Description

Les patrons servent à documenter des bonnes pratiques basées sur l'expérience. Ils sont le résultat d'une synthèse de l'expérience acquise par les ingénieurs. Les patrons spécifient des solutions à des problèmes qui ne peuvent pas être résolus par un composant isolé: La description de la plupart des patrons implique plusieurs rôles qui peuvent être joués par plusieurs composants d'un logiciel. Par exemple le patron Observer implique deux rôles qui sont le sujet et l'observateur^[6].

Les patrons apportent un vocabulaire commun entre l'architecte et le programmeur: Si le programmeur connait le patron de conception Observer, alors l'architecte n'aura pas besoin de lui donner de longues explications et le dialogue se limitera à « ici j'ai utilisé un Observer »^[6].

En programmation informatique, les patrons de conception peuvent être utilisés avant, pendant, ou après le travail de programmation: Utilisé avant, le programmeur utilisera le patron comme guide lors de l'écriture du code source. Utilisé après il servira comme exemple pour relier différents modules de code source déjà écrits, ce qui implique d'écrire le code source nécessaire à leur liaison, et le code qui les fera correspondre au patron de conception. Utilisé pendant le travail de programmation, le programmeur constatera que le code qui vient d'être écrit a des points communs avec un patron existant et effectuera les modifications nécessaires pour que le code corresponde au patron^[7].

Histoire

Formalisés dans le livre du « Gang of Four » (GoF, Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides) intitulé « Design Patterns -- Elements of Reusable Object-Oriented Software » (voir bibliographie) en 1995, les patrons de conception tirent leur origine des travaux de l'architecte Christopher Alexander dans les années 70.

Citations

• « Chaque patron décrit un problème qui se manifeste constamment dans notre environnement, et donc décrit le cœur de la solution à ce problème, d’une façon telle que l’on puisse réutiliser cette solution des millions de fois, sans jamais le faire deux fois de la même manière » — Christopher Alexander, 1977.
• « Les patrons offrent la possibilité de capitaliser un savoir précieux né du savoir-faire d’experts » — Buschmann, 1996.

Formalisme

La description d'un patron de conception suit un formalisme fixe :

• Nom
• Description du problème à résoudre
• Description de la solution : les éléments de la solution, avec leurs relations. La solution est appelée patron de conception.
• Conséquences : résultats issus de la solution.

Ce formalisme aide surtout à mieux comprendre l'utilisation et la logique interne de chaque patron, mais ne correspond pas à l'usage habituel du terme. Le mot structure serait peut-être plus adapté.

Un aspect de construction plus important est l'orthogonalité: chaque patron doit correspondre à une approche différente, qui ne répète pas les idées ou stratégies présentes dans d'autres patrons. Cette qualité devrait permettre d'aider le concepteur à décortiquer un problème et à en résoudre chaque aspect d'une façon organisée, ainsi que de combiner les patrons pour construire une solution. Certains auteurs voient alors un manque d'orthogonalité dans les patrons GoF, tandis que d'autres en proposent encore davantage (Vlissides, Grand).

Patrons de conception du GoF

Les patrons de conception les plus connus sont au nombre de 23. Ils sont couramment appelés « patrons GoF » (de « Gang of Four », d'après les quatre créateurs du concept)^[8]. Le patron Modèle-Vue-Contrôleur (MVC) est une combinaison des patrons Observateur, Stratégie et Composite.

On distingue trois familles de patrons de conception selon leur utilisation :

• de construction : ils définissent comment faire l'instanciation et la configuration des classes et des objets.
• structuraux : ils définissent comment organiser les classes d'un programme dans une structure plus large (séparant l'interface de l'implémentation).
• comportementaux : ils définissent comment organiser les objets pour que ceux-ci collaborent (distribution des responsabilités) et expliquent le fonctionnement des algorithmes impliqués.

Création

• Fabrique abstraite (Abstract Factory)
• Monteur (Builder)
• Fabrique (Factory Method)
• Prototype (Prototype)
• Singleton (Singleton)

Structure

• Adaptateur (Adapter)
• Pont (Bridge)
• Objet composite (Composite)
• Décorateur (Decorator)
• Façade (Facade)
• Poids-mouche ou poids-plume (Flyweight)
• Proxy (Proxy)

Comportement

• Chaîne de responsabilité (Chain of responsibility)
• Commande (Command)
• Interpréteur (Interpreter)
• Itérateur (Iterator)
• Médiateur (Mediator)
• Mémento (Memento)
• Observateur (Observer)
• État (State)
• Stratégie (Strategy)
• Patron de méthode (Template Method)
• Visiteur (Visitor)
• Fonction de rappel (Callback)

Patrons GRASP

Les patrons GRASP (General Responsibility Assignment Software Patterns (or Principles) GRASP (object-oriented design)) sont des patrons créés par Craig Larman qui décrivent des règles pour affecter les responsabilités aux classes d'un programme orienté objets pendant la conception, en liaison avec la méthode de conception BCE (pour « Boundary Control Entity » - en français MVC « Modèle Vue Contrôleur »)^[9] :

• Responsabilités
• Expert
• Créateur
• Faible couplage
• Forte cohésion
• Contrôleur
• Polymorphisme
• Indirection
• Fabrication pure

Autres patrons de conception

• Inversion de contrôle
• Injection de dépendances

Thème connexe

Sur les autres projets Wikimedia :

• « Patron de conception », sur Wikimedia Commons (ressources multimédia)
• « Patron de conception », sur Wikibooks (livres pédagogiques)

• Antipattern
• Liste des patrons de conception

Références

1. ↑ (en),Rajib Mall,Fundamentals of Software Engineering,PHI Learning Pvt. Ltd.,(ISBN 9788120338197),page 266
2. ↑ Laurent Debrauwer,Design patterns pour Java : Les 23 modèles de conception : descriptions et solutions illustrées en UML 2 et Java. Editions ENI. 2009. (ISBN 9782746050570)
3. ↑ (en)Frank Buschmann - Kevlin Henney - Douglas C. Schmidt,Pattern-oriented software architecture: On patterns and pattern languages,John Wiley and Sons - 2007,(ISBN 9780471486480),page 13
4. ↑ (en),Linda Rising,The patterns handbook: techniques, strategies, and applications,Cambridge University Press - 1998,(ISBN 9780521648189),page 311
5. ↑ ^{a, b et c} (en)Rajib Mall,Fundamentals of Software Engineering,PHI Learning Pvt. Ltd.,(ISBN 9788120338197),page 267
6. ↑ ^{a et b} (en)Frank Buschmann - Kevlin Henney - Douglas C. Schmidt,Pattern-oriented software architecture: On patterns and pattern languages,John Wiley and Sons - 2007,(ISBN 9780471486480)
7. ↑ (en) Stephen Hendrick Kaisler. Software paradigms. John Wiley and Sons. 2005. (ISBN 9780471483472). p. 39
8. ↑ Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (trad. Jean-Marie Lasvergères), Design Patterns - Catalogue de modèles de conceptions réutilisables [détail des éditions] 
9. ↑ UML 2 et les Design Patterns - Craig Larman (3^e édition) ISBN 2-7440-7090-4

Bibliographie

• Christopher Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King and S. Angel, (1977), A Pattern Language : Towns, Buildings, Construction, ISBN 0-19-501919-9
• Design patterns - Tête la première, de Eric Freeman, Elisabeth Freeman, Kathy Sierra et Bert Bates. ISBN 2-84177-350-7 (1^re édition, septembre 2005)
• Pattern Languages of Program Design - James O. Coplien, Douglas C. Schmidt. (1995), ISBN 0-201-60734-4