Les patterns
“Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.”
« Chaque modèle décrit un problème récurent dans notre environnement, et puis décrit le noyau de la solution à ce problème, de telle manière que vous puissiez employer cette solution plus d'un million de fois, sans jamais devoir le faire de la même manière deux fois. »
Christopher AlexanderAlexander évoquait les “Patterns” (en français, « patrons, modèles ») dans le cadre de la construction d'édifices et de villes, mais cette définition colle de très près à la programmation objets.
Développé dans les années 70, le concept de “design patterns” (en français, « motifs de conception ») fait l'objet d'un ouvrage de référence publié en 1994 (Design Patterns : Elements of reusable object oriented softwareref 1), identifiant 23 motifs de conceptions, chacun offrant une solution à un problème récurrent de la conception orientée-objet.
Craig Larman3 nous fournit une autre contribution de référence qui décrit des modèles de conception plus intuitifs : les GRASP “Patterns”1.
NB : Nous retrouvons souvent l'acronyme GOF [“Gang Of Four”4], qui désigne les 4 personnes qui consacrèrent leurs recherches aux design patterns : Erich Gamma, Ralph Johnson, Richard Helm, John Vlissides.6
Synthèse : Un “pattern”1, est donc un document qui décrit une solution générale à un problème qui revient souvent.
Structure d'un pattern
Le langage de “pattern”1 est défini par la structure suivante :
- nom du “pattern”1 : le nom d'un “pattern”1 permet tout d'abord de faciliter la communication en nous permettant d'identifier précisément une situation lors du développement d'applications, sans que notre interlocuteur ne doive maîtriser le même langage de programmation que nous. Nous pouvons atteindre un haut degré d'abstraction en utilisant le nom correct du “pattern”1, sans devoir évoquer la moindre ligne de code.
- problème : le problème, ou contexte, décrit dans quelle situation le “pattern”1 peut nous aider. Souvent, les conditions du problème sont ajoutées à sa description.
- solution : la solution ne décrit pas des éléments concrets de "design"7 ou des implémentations précises. Il s'agit d'un modèle qu'il est possible d'appliquer à de nombreuses situations différentes, mais qui toutes amènent au problème décrit.
- conséquences du “pattern”1 : les conséquences permettent d'évaluer les coûts et bénéfices des différentes alternatives possibles.
Catalogue des 23 patterns du GOF
6- “Creational Patterns” (en français, « motifs de création ») :
- “Abstract Factory” (en français, « fabrique abstraite ») : permet un point d'accès à la création de familles d'objets liés entre eux ou dépendant les uns des autres, indépendament de leurs classes concrètes.
- “Builder” (en français, « constructeur ») : permet de séparer la construction d'un objet complexe de sa représentation, de telle manière que le même processus de construction puisse différentes représentations.
- “Factory Method” (en français, « fabrique ») : permet un point d'accès à la création d'objets tout en laissant aux sous-classes le soin de la sélection de la classe qui devra être instanciée.
- “Prototype” (en français, « prototype ») : permet de spécifier le type d'objets à créer en utilisant une instance prototype. Le prototype sera copié pour créer les nouveaux objets.
- “Singleton” (en français, « instance unique ») : permet de nous assurer qu'une seule instance d'un objet sera créée, et de nous fournir un point d'accès vers ce dernier.
- “Structural Patterns” (en français, « motifs de structure ») :
- “Adapter” (en français, « adaptateur ») : permet d'adapter par encapsulatrion les signatures de methodes d'une classe vers une autre.
- “Bridge” (en français, « pont ») : permet de différencier une abstraction de son implémentation, permettant à chacune d'évoluer indépendamment.
- “Composite” (en français, « objet composite ») : permet de traiter une structure d'objets de manière uniforme.
- “Decorator” (en français, « décorateur ») : permet de créer une classe qui étend les capacités d'une ou de plusieurs classes.
- “Facade” (en français, « façade ») : nous facilite l'usage d'un sous-système, en définissant une interface de haut niveau qui unifie les interfaces du sous-système.
- “Flyweight” (en français, « poids-mouche, ou poids-plume ») : partage des éléments nécessaires à un grand nombre d'objets, ce qui évite de les maintenir en duplicats dans les différents objets qui en ont besoin.
- “Proxy” (en français, « procuration, substitut ») : oblige les appels des méthodes d'un objet à passer par un objet (“proxy”21) qui agit comme un substitut pour l'autre objet, déléguant les appels de méthodes à cet objet. Les classes sont créées de telle sorte que l'objet client ne peut voir qu'il travaille avec un “proxy”21.
- “Behavioral Patterns” (en français, « motifs de comportement ») :
- “Chain of Responsibility” (en français, « chaîne de responsabilité ») : permet un plus faible couplage dans le cas où un élément est attendu par un grand nombre d'objets, en passant l'élément à un seul objet qui le passe au suivant, et ainsi de suite au long de la chaîne.
- “Command” (en français, « commande ») : encapsule une requête dans un objet, et permet les files d'attentes, les journalisations , et “undo” (en français, « annulation de la dernière opération »).
- “Interpreter” (en français, « interpréteur ») : définit un langage ainsi que sa grammaire, et fournit un interpreteur pour utiliser la représentation du langage.
- “Iterator” (en français, « itérateur ») : fournit un accès aux éléments d'un agrégat d'objets indépendament de la représentation réelle de l'agrégation (le type de tableau, de collection utilisé).
- “Mediator” (en français, « médiateur ») : définit un objet qui encapsule la manière dont un ensemble d'objets interagissent.
- “Memento” (en français, « mémento ») : permet, sans violer l'encapsulation, de capturer et d'externaliser l'état interne d'un objet pour le mémoriser afin de le restaurer par la suite si nécessaire.
- “Observer” (en français, « observateur ») : permet aux objets d'enregistrer dynamiquement les dépendances entre objets, de telle sorte qu'un objet qui change d'état le notifie à tous ceux qui dépendent de lui, sans qu'il ne les connaisse réellement.
- “State” (en français, « état ») : permet d'altérer le comportement d'un objet en fonction de son état interne.
- “Strategy” (en français, « stratégie ») : définit une famille d'algorithmes, encapsule chacun d'eux, et les rend interchangeable.
- “Template Method” (en français, « modèle de méthode ») : définit le squelette d'un algorithme dans une opération, déléguant certaines étapes aux sous-classes. Il permet de redéfinir certaines étapes d'un algorithme sans en changer la structure.
- “Visitor” (en français, « visiteur ») : permet de séparer un algorithme de la structure d'un objet.
Remarque
Dans les pages qui suivent, les concepts employés se veulent indépendants d'un langage de programmation. Par exemple, le terme interface sera souvent employé pour évoquer ce qui se situe entre deux éléments, et non pour évoquer une classe de type interface en orienté-objet.
English translation
You have asked to visit this site in English. For now, only the interface is translated, but not all the content yet.If you want to help me in translations, your contribution is welcome. All you need to do is register on the site, and send me a message asking me to add you to the group of translators, which will give you the opportunity to translate the pages you want. A link at the bottom of each translated page indicates that you are the translator, and has a link to your profile.
Thank you in advance.
Document created the 22/05/2005, last modified the 26/10/2018
Source of the printed document:https://www.gaudry.be/en/uml-pattern.html
The infobrol is a personal site whose content is my sole responsibility. The text is available under CreativeCommons license (BY-NC-SA). More info on the terms of use and the author.
- ↑ design patterns : corresponds to « motifs de conception » en français
- ↑ Craig Larman : informaticien canadien spécialisé dans l'analyse et conception orientée objet, auteur des GRASP Patterns.
- ↑a,b GOF : Nous retrouvons souvent l'acronyme GOF [“Gang Of Four”4], qui désigne les 4 personnes qui consacrèrent leurs recherches aux design patterns : Erich Gamma, Ralph Johnson, Richard Helm, John Vlissides.
- ↑ design : corresponds to « conception » en français
- ↑ Creational Patterns : corresponds to « motifs de création » en français
- ↑ Abstract Factory : corresponds to « fabrique abstraite » en français
- ↑ Builder : corresponds to « constructeur » en français
- ↑ Factory Method : corresponds to « fabrique » en français
- ↑ Prototype : corresponds to « prototype » en français
- ↑ Singleton : corresponds to « instance unique » en français
- ↑ Structural Patterns : corresponds to « motifs de structure » en français
- ↑ Adapter : corresponds to « adaptateur » en français
- ↑ Bridge : corresponds to « pont » en français
- ↑ Composite : corresponds to « objet composite » en français
- ↑ Decorator : corresponds to « décorateur » en français
- ↑ Facade : corresponds to « façade » en français
- ↑ Flyweight : corresponds to « poids-mouche, ou poids-plume » en français
- ↑ Behavioral Patterns : corresponds to « motifs de comportement » en français
- ↑ Chain of Responsibility : corresponds to « chaîne de responsabilité » en français
- ↑ Command : corresponds to « commande » en français
- ↑ undo : corresponds to « annulation de la dernière opération » en français
- ↑ Interpreter : corresponds to « interpréteur » en français
- ↑ Iterator : corresponds to « itérateur » en français
- ↑ Mediator : corresponds to « médiateur » en français
- ↑ Memento : corresponds to « mémento » en français
- ↑ Observer : corresponds to « observateur » en français
- ↑ State : corresponds to « état » en français
- ↑ Strategy : corresponds to « stratégie » en français
- ↑ Template Method : corresponds to « modèle de méthode » en français
- ↑ Visitor : corresponds to « visiteur » en français
References
- Design Patterns : Erich Gamma, Ralph Johnson, Richard Helm, John Vlissides,
Elements of Reusable Object-Oriented Software
(1994)
These references and links indicate documents consulted during the writing of this page, or which may provide additional information, but the authors of these sources can not be held responsible for the content of this page.
The author This site is solely responsible for the way in which the various concepts, and the freedoms that are taken with the reference works, are presented here. Remember that you must cross multiple source information to reduce the risk of errors.