1. Légende
1.1. Pattern de création
1.2. Pattern structural
1.3. Pattern comportemental
2. Patterns de création
2.1. Abstract Factory
2.1.1. Permet à un client de créer des familles d’objets sans spécifier leurs classes concrètes.
2.1.2. Par exemple
2.1.2.1. On peut définir une Abtract Factory gérant des véhicules.
2.1.2.2. Suivant le type de véhicule, le modèle, etc... , on va pouvoir créer une Factory concrète chargée d'implémenter les méthodes de création des différentes parties du véhicule, et de s'assurer ainsi que toutes les méthodes pour créer un véhicule seront présentes dans la Factory Concrète.
2.2. Factory Method
2.2.1. Ce pattern ressemble à l’abstract factory en permettant à une méthode de créer des instances dérivées d’une classe mère.
2.2.2. Par exemple
2.2.2.1. On peut supposer une gestion de document de différents types, des CV, des articles, des news, etc, chacun ayant sa structure interne propre.
2.2.2.2. La factory method de la classe « document » permettra à l’application de gérer tout type de document et sera capable de créer les instances des parties différentes du document en fonction de son type (un CV comportera les parties identité, diplômes et expérience, un article comportera les parties titre, introduction, texte et conclusion, ainsi de suite…).
2.3. Builder
2.3.1. Le pattern Builder permet d'encapsuler la construction d’un objet et permettre de le construire par étapes.
2.3.2. Ce pattern décrit comment séparer la construction d’un objet complexe de sa représentation.
2.3.3. Il permet également de construire un objet de façon dite "fluent" en chaînant l'allocation des différents propriétés de l'objet, tout en permettant de ne renseigner qu'une partie de ces propriétés.
2.4. Prototype
2.4.1. Le prototype est une instance correctement initialisée servant de modèle à la création d’un clone. Il permet de créer de nouvelles instances en copiant des instances existantes.
2.4.2. Ce pattern permet par exemple d’implémenter une collection d’objets décrivant des formes géométriques qui, au lieu d’être utilisées directement pour créer des dessins, seront d’abord dupliqués comme on pioche dans un stock d’outils.
2.4.3. Vous pouvez utiliser ce pattern quand la création d’une instance d’une classe donnée est coûteuse ou compliquée.
2.5. Singleton
2.5.1. Garantit qu’un objet et un seul est créé.
2.5.2. Il permet de s’assurer qu’une seule instance d’une classe ne peut exister à un moment donné et fournit un point d’accès vers cette instance.
2.5.3. Par exemple, une application gérant une machine outil voudra s’assurer qu’il ne peut pas y avoir au même moment deux instances de la classe permettant de commander la machine afin d’éviter que les ordres envoyés par plusieurs instances ne se mélangent.
2.5.4. De façon générale dès qu’un objet interagit avec une ressource unique qu’il se réserve il est classique de le voir implémenter ce pattern.
3. Patterns structuraux
3.1. Adapter
3.1.1. Modifie l’interface d’une ou plusieurs classes
3.1.2. L’adapter est un procédé permettant d’habiller en quelque sorte une classe en la faisant ressembler, du point de vue de son interface, à une autre.
3.1.3. Par exemple
3.1.3.1. On peut supposer une application qui travaille sur des objets de classe A exposant les méthodes M1 et M2.
3.1.3.2. L’évolution du produit fait que la classe A est abandonnée au profit d’une classe B qui fait ce que faisait A mais différemment.
3.1.3.3. Pour ne pas perturber l’ancienne application et dans l’attente de la reprogrammer on concevra un adaptateur qui se présentera comme étant de classe A avec les méthodes M1 et M2 et qui en réalité instanciera un objet de classe B avec d’autres méthodes qui feront le travail.
3.1.3.4. L’appel de la méthode M1 par l’application sera traduite par l’adaptateur en l’appel des méthodes X1, X2 et X3 du nouvel objet. De fait, l’application aura toujours l’impression de travailler sur la classe A alors que la librairie sous-jacente sera totalement différente. Les nouvelles applications utiliseront elles directement la nouvelle classe.
3.1.4. De façon plus générale, l'Adapter permet de faire fonctionner ensemble des interfaces initialement incompatibles.
3.2. Bridge
3.2.1. Le pattern Bridge permet de faire varier l’implémentation et l’abstraction en plaçant les deux dans des hiérarchies de classes séparées.
3.2.2. Ce DP créé un pont entre une classe et l’implémentation de tout ou partie de son code.
3.2.3. Par exemple
3.2.3.1. On peut l'utiliser lorsqu’on sait que l’implémentation d’une classe risque de changer dans le futur alors qu’on ne désire pas modifier l’application utilisatrice.
3.2.3.2. On fige l’interface, utilisée par le client, et on délègue l’implémentation à d’autres classes.
3.2.3.3. A l'exécution, l'appel à l'interface fournira une classe d'implémentation contenant le code utile.
3.3. Composite
3.3.1. Ce pattern permet de créer des structures arborescentes d’objets ayant une relation tout/partie.
3.3.2. Il permet aux clients de traiter les objets individuels et les compositions de façon uniforme.
3.4. Decorator
3.4.1. Enveloppe un objet pour fournir un nouveau comportement
3.4.2. Avec ce pattern on dispose d’un moyen efficace pour accrocher de nouvelles fonctions à un objet dynamiquement lors de l’exécution.
3.4.3. Cela ressemble à la fois un peu aux interfaces et à l’héritage mais c’est une troisième voie offrant des avantages différents.
3.4.4. Les nouvelles fonctionnalités sont contenues dans des objets, l’objet parent étant dynamiquement mis en relation avec ces derniers pour en utiliser les capacités.
3.5. Facade
3.5.1. Ce pattern permet de masquer la complexité de tout un système.
3.5.2. Par exemple
3.5.2.1. Une classe GestionDesStocks permettra de manipuler depuis d’autres endroits dans une chaîne de gestion commerciale l’ensemble des modules afférents à la gestion des stocks.
3.5.2.2. Bien implémentée, ce pattern permet une incroyable modularité et la réutilisation simplifiée du code dans des applications complexes.
3.5.2.3. L’implémentation “moderne” doit pour être fortement découplée souvent passer par une conteneur IoC par exemple mais ce n’est pas une obligation du pattern.
3.6. Flyweight
3.6.1. Le pattern Flyweight permet d'utiliser une instance d’une classe au sein de plusieurs « instances virtuelles », afin de limiter la redondance d'informations identiques dans les objets.
3.7. Proxy
3.7.1. Enveloppe un objet et en contrôle l’accès.
3.7.2. Ce pattern définit comment un objet permet d’en contrôler un autre.
3.7.3. On l’utilise très fréquemment pour manipuler localement la représentation d’un objet distant (Remoting/WCF, services web, etc.).
4. Patterns comportementaux
4.1. Chain of Responsibility
4.1.1. Avec le pattern Chaîne de responsabilité, vous créez une chaîne d’objets qui examinent une requête. Chaque objet considère la requête à son tour puis soit :
4.1.1.1. la traite
4.1.1.2. la transmet à l’objet suivant dans la chaîne
4.1.2. Exemple
4.1.2.1. le système d'exceptions
4.1.2.1.1. catch
4.1.2.1.2. throw
4.2. Command
4.2.1. Encapsule une requête sous forme d’objet
4.2.2. Lorsqu’un système doit gérer de nombreuses commandes qui peuvent être mises en attente et être éventuellement annulées, il est intéressant de transformer chaque commande en un objet placé dans une liste.
4.2.3. Exemple
4.2.3.1. Un programme de type calculatrice permettant un niveau quelconque de "undo".
4.2.3.2. Chaque élément du calcul est un objet placé dans une liste.
4.2.3.3. Le module de calcule traite la liste, la touche "undo" efface le dernier objet de la liste.
4.3. Interpreter
4.3.1. le pattern Interpreter permet de définir des classes pour représenter la grammaire et un interpreter pour interpréter les phrases. On utilise une classe pour représenter chaque règle du langage.
4.4. Iterator
4.4.1. Fournit un moyen de naviguer dans une collection d’objets sans en exposer l’implémentation
4.5. Mediator
4.5.1. Ce pattern définit le fonctionnement d’un objet qui gère les interactions entre d’autres objets. C’est un médiateur.
4.5.2. Les objets considérés ont ainsi un couplage très faible entre eux ce qui coïncide avec les guidelines les plus récentes.
4.5.3. Par exemple
4.5.3.1. Un objet ChatRoom permet la communication entre des objets clients, chaque client peut communiquer avec d’autres clients mais aucun n’a accès directement aux autres clients.
4.5.3.2. Tous communiquent en utilisant les services du médiateur.
4.6. Memento
4.6.1. Ce pattern met en place un mécanisme permettant de capturer l’état interne d’un objet pour le stocker et restaurer ultérieurement l’objet dans le même état.
4.6.2. Il peut être étendue en réalité à tout système de sérialisation.
4.6.3. Les langages .NET comme C# exploitent les mécanismes de sérialisation offert par le framework ou des librairies tierces (Json.Net par exemple), ces mécanismes n’existaient pas “out of the box” à la création du catalogue du Gang Of Four.
4.6.4. Avec les langages plate-formes modernes comme C# et .NET le pattern memento perd de son intérêt mais il existe tout de même des cas où il peut encore jouer un rôle.
4.7. Null Object
4.7.1. Un objet null est un objet qui a un comportement défini comme neutre.
4.8. Observer
4.8.1. Lorsque plusieurs objets doivent être avertis d’une notification il faut trouver un moyen pour distribuer le message. C’est ce que propose le pattern Observer.
4.8.2. Ici aussi on peut reconnaitre des éléments des langages modernes. C# sait par exemple gérer les évènements à diffusion multiple (multicast events) qui ne sont autres qu’une façon d’implémenter le pattern observer.
4.9. State
4.9.1. Ce pattern encapsule des comportements basés sur des états et utilise la délégation pour permuter ces comportements.
4.9.2. Il décrit comment un objet peut modifier son comportement quand son état change.
4.9.3. Par exemple
4.9.3.1. Un objet compte bancaire peut gérer différemment les retraits, le paiement d’intérêts et les frais de fonctionnement selon le solde que présente le compte.
4.9.3.2. L’état interne peut être représenté par un objet qui applique les nouvelles règles.
4.9.3.3. L’objet "compte bancaire" possède alors un objet "état" approprié selon sa balance.
4.9.3.4. Cet état peut ainsi permettre d'ajuster le comportement de l'objet.
4.10. Strategy
4.10.1. Encapsule des comportements interchangeables et emploie la délégation pour décider lequel utiliser.
4.10.2. Pourvoir modifier un algorithme de façon transparente peut être très utile.
4.10.3. Par exemple
4.10.3.1. On peut supposer une application permettant de trier des éléments selon des méthodes différentes.
4.10.3.2. Ce pattern explique comment mettre en œuvre le mécanisme rendant le choix de l’algorithme transparent pour l’objet l’utilisant.
4.11. Template Method
4.11.1. Les sous-classes décident de la façon d’implémenter les étapes d’un algorithme
4.11.2. Ce DP définit comment mettre en place un algorithme dont les étapes sont figées mais dont la réalisation de ces dernières peut être déléguée à d’autres objets offrant des variations de traitement.
4.11.3. Ce pattern crée la trame immuable d’un traitement tout en laissant la liberté de réalisation de chaque étape à d’autres intervenants du système.
4.11.4. Par exemple
4.11.4.1. On peut définir dans un objet conteneur de données une méthode ExportData permettant d’exporter des données sous un format quelconque mais segmentant l’opération en étapes précises :
4.11.4.1.1. OuvrirDestination
4.11.4.1.2. EcrireEntête
4.11.4.1.3. EcrireCorps
4.11.4.1.4. EcrirePied
4.11.4.1.5. FermerDestination
4.11.4.2. Toute exportation sera toujours composée de ces cinq étapes.
4.11.4.3. Ensuite on peut implémenter des objets d’exportation implémentant ces cinq méthodes (exportation vers XML, CSV, etc.).
4.11.5. Ce pattern est extrêmement souple et s’adapte à de nombreux cas de figure.
4.12. Visitor
4.12.1. Utilisez le pattern Visiteur quand vous voulez ajouter des capacités à un ensemble composite d’objets et que l’encapsulation n’est pas importante.
4.12.2. Le visiteur peut être vu comme l’opération complémentaire à l’itérateur.
4.12.3. Le visiteur est une classe définissant une opération sur une autre classe. L’objet visité autorise l’appel d’un visiteur en publiant généralement une méthode prenant en paramètre une instance de visiteur.
4.12.4. Comme il est ensuite possible de créer des dérivées de la classe visiteuse, on peut créer autant d’opérations différentes pouvant être appliquée à la classe visitée sans avoir à en modifier le code.
4.12.5. Par exemple
4.12.5.1. Ce pattern est très efficace pour laisser ouverte la définition de nouveaux traitements pouvant s’appliquer sur des collections d’objets (liste de clients, de salariés, articles…).
4.12.5.2. La liste expose une méthode de type TraiterAvec(TypeVisiteur leVisitieur) dont le rôle est de balayer chaque élément en lui appliquant le visiteur.
4.12.5.3. On peut ainsi, pour une liste de clients, créer un visiteur « promotion » qui créditera de points cadeaux les clients répondant à certains critères, un autre jour on pourra créer un autre visiteur envoyant un mail aux clients répondant à d’autres critères, etc...