IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Comprendre les différents design patterns de structuration

Date de publication : 05/03/2011. Date de mise à jour : 05/03/2011.

Par Jean-Michel Ormes (page de Jean-Michel Ormes)
 

Comprendre les différents design patterns de structuration fait partie d'une suite d'articles que j'ai écrits pour expliquer comment implémenter les 23 modèles de conception les plus connus. Dans cet article, nous allons nous concentrer sur le fonctionnement des design patterns liés à la construction d'objets, les deux autres familles feront le sujet d'un autre article. N'hésitez pas à laisser votre avis sur le contenu de l'article directement via le forum : 15 commentaires Donner une note à l´article (5)

       Version PDF (Miroir)   Version hors-ligne (Miroir)
Viadeo Twitter Facebook Share on Google+        



1. Introduction
2. Problématique générale
3. Les modèles de structuration
3.1. Adaptateur (Adaptator)
3.1.1. Définition
3.1.2. Diagramme de classe
3.1.3. Implémentation en C#
3.2. Pont (Bridge)
3.2.1. Définition
3.2.2. Diagramme de classe
3.2.3. Implémentation en C#
3.3. Objet composite (Composite)
3.3.1. Définition
3.3.2. Diagramme de classe
3.3.3. Implémentation en C#
3.4. Décorateur (Decorator)
3.4.1. Définition
3.4.2. Diagramme de classe
3.4.3. Implémentation en C#
3.5. Façade (Facade)
3.5.1. Définition
3.5.2. Diagramme de classe
3.5.3. Implémentation en C#
3.6. Poids-mouche (Flyweight)
3.6.1. Définition
3.6.2. Diagramme de classe
3.6.3. Implémentation en C#
3.7. Proxy (Proxy)
3.7.1. Définition
3.7.2. Diagramme de classe
3.7.3. Implémentation en C#
4. Liens
5. Remerciements


1. Introduction

Qu'est-ce qu'un design pattern (ou patron de conception)? Il s'agit tout simplement d'un schéma qui forme une solution à un problème connu ou récurrent. Ce sont des solutions connues et dont la conception est due à l'expérience de programmeurs. Le concept de design patterns est né des travaux de quatre personnes (Erich Gamma, Richard Helm, Ralph Johnson, et John Vlissides plus communément appelés « Gang of Four ») dans leur ouvrage « Design Patterns : Elements of Reusable Object-Oriented Software ». De façon générale, on utilise un design pattern pour diminuer le temps nécessaire au développement d'une application et pour augmenter la qualité du résultat attendu à un traitement donné.


2. Problématique générale

Afin de mieux illustrer la mise en œuvre des modèles de conception, nous allons prendre un exemple d'étude de cas. Vous êtes à la tête d'un géant constructeur d'ordinateurs et de pièces détachées. Il vous faut imaginer tout le processus, allant de la création des ordinateurs ou des pièces jusqu'à leur livraison.


3. Les modèles de structuration

Les patterns de structuration permettent de résoudre des problèmes liés à la structuration des classes et de leur interface.


3.1. Adaptateur (Adaptator)


3.1.1. Définition


3.1.2. Diagramme de classe


3.1.3. Implémentation en C#


3.2. Pont (Bridge)


3.2.1. Définition


3.2.2. Diagramme de classe


3.2.3. Implémentation en C#


3.3. Objet composite (Composite)


3.3.1. Définition


3.3.2. Diagramme de classe


3.3.3. Implémentation en C#


3.4. Décorateur (Decorator)


3.4.1. Définition


3.4.2. Diagramme de classe


3.4.3. Implémentation en C#


3.5. Façade (Facade)


3.5.1. Définition

Le pattern Façade est utilisé pour fournir une interface simple d'un environnement complexe. Dans le cadre de notre étude, imaginons le scénario suivant : Un client désire régler son achat par CB en ligne. Si nous procédons par étape, le client entre dans un premier temps les informations relatives à sa CB, puis valide. Se déroule ensuite une procédure que l'on appelera " la demande d'autorisation " qui consiste à vérifier que le compte du client est bien provisionné. Dans cette demande d'autorisation, il y à deux acteurs qui entrent en jeu : le serveur A de la banque du site et le serveur B de la banque du client. A se charge d'acquérir toutes les informations concernant la transaction (montant, n° CB, etc..) puis transmet ces informations à B qui effectue ses vérifications et fait le chemin en sens inverse pour donner l'autorisation à A. Comme vous pouvez l'imaginer, tout ce processus peut être assez complexe à gérer (notamment en terme de sécurité). Le pattern Façade permettrait d'encapsuler les différentes étapes de ce process en une seule interface plus simple.


3.5.2. Diagramme de classe


3.5.3. Implémentation en C#


3.6. Poids-mouche (Flyweight)


3.6.1. Définition


3.6.2. Diagramme de classe


3.6.3. Implémentation en C#


3.7. Proxy (Proxy)


3.7.1. Définition


3.7.2. Diagramme de classe


3.7.3. Implémentation en C#


4. Liens

Je vous invite à lire également ces liens :



5. Remerciements

Je tiens à remercier ... pour sa relecture et les corrections apportées.



               Version PDF (Miroir)   Version hors-ligne (Miroir)

Valid XHTML 1.0 TransitionalValid CSS!