Design Patterns

 

1       Origine du concept 1

2       Patron de conception logicielle. 2

3       Documentation d’un patron de conception. 2

3.1        Avantages des patrons de conception. 2

3.2        Inconvénients des patrons de conception. 2

4       Types de patrons de conception : 2

4.1        Patrons de création (Creational Patterns). 3

4.2        Patrons structurels (Structural Patterns). 3

4.3        Patrons comportementaux (Behavioral Patterns). 3

5       Exemples. 4

5.1        Singleton. 4

5.2        Strategy. 4

5.3        Composite. 5

 

1          Origine du concept

Le concept de patron de conception trouve son origine dans l’architecture. En 1977, Christopher Alexander, architecte, définit les patrons de conception comme :

• La description d’un problème récurrent et de sa solution.
• Une solution pouvant être utilisée des millions de fois sans jamais être exactement identique.
• Une forme de conception, un pattern ou modèle.

Ce concept a attiré l’attention des chercheurs en programmation orientée objet dès les années 1980.

Le terme est popularisé par le GOF (Gang of Four) : Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides, dans leur ouvrage Design Patterns: Elements of Reusable Object-Oriented Software, publié chez Addison-Wesley en 1995.

 

2          Patron de conception logicielle

Un patron de conception (design pattern) est la description d’une solution classique à un problème récurrent.

• Il décrit une partie de la solution, en précisant ses relations avec le système et les autres parties.
• Il s’agit d’une technique d’architecture logicielle, et non pas :
• Une brique : l’application d’un pattern dépend de l’environnement.
• Une règle : un pattern ne s’applique pas mécaniquement.
• Une méthode : il ne guide pas la prise de décision ; il représente une décision déjà prise.

 

3          Documentation d’un patron de conception

Les principaux éléments de description d’un pattern sont :

• Nom du pattern : résume le problème de conception.
• Intention : courte description des objectifs et de la raison d’être du pattern.
• Indications d’utilisation : situations où le pattern peut être utile.
• Motivation : illustre un cas particulier d’utilisation du pattern.
• Structure : représentation graphique des classes du modèle.

 

3.1        Avantages des patrons de conception

• Capitalisation de l’expérience : réutilisation de solutions éprouvées.
• Gain de temps : accélération de la con

3.2        Inconvénients des patrons de conception

• Nécessité d’un effort de synthèse important pour identifier et abstraire les patterns pertinents.
• Apprentissage et expérience indispensables pour les utiliser correctement.
• Les patterns peuvent se dissoudre lorsqu’ils sont appliqués.
• Nombre élevé de patterns : 23 dans l’ouvrage du GOF, d’autres sont publiés régulièrement, parfois similaires.
• Certains patterns sont interdépendants : certains s’appuient sur d’autres patterns.

4          Types de patrons de conception :

 

4.1        Patrons de création (Creational Patterns)

Ces patrons concernent la manière dont les objets sont créés, en cachant la complexité d’instanciation et en rendant le système plus flexible.
Exemples :

·         Singleton : assure une seule instance d’une classe.

·         Factory Method : définit une interface pour créer un objet, mais laisse les sous-classes décider de la classe concrète à instancier.

·         Abstract Factory : fournit une interface pour créer des familles d’objets liés.

·         Builder : sépare la construction d’un objet complexe de sa représentation.

·         Prototype : crée des objets en copiant un prototype existant.

4.2         Patrons structurels (Structural Patterns)

Ces patrons concernent la composition des classes et objets pour former des structures plus grandes et flexibles.
Exemples :

• Composite : permet de traiter de manière uniforme des objets simples et composés.
• Adapter : adapte une interface existante à une interface attendue.
• Decorator : ajoute dynamiquement des responsabilités à un objet.
• Facade : fournit une interface simplifiée à un ensemble de classes.
• Bridge : sépare l’abstraction de son implémentation pour qu’elles puissent évoluer indépendamment.
• Flyweight : réduit le nombre d’objets créés en partageant les instances similaires.
• Proxy : fournit un substitut ou un représentant d’un objet pour contrôler l’accès.

 

4.3         Patrons comportementaux (Behavioral Patterns)

Ces patrons définissent la manière dont les objets interagissent et communiquent.
Exemples :

• Strategy : encapsule des algorithmes interchangeables.
• Observer : définit une dépendance un-à-plusieurs entre objets pour notifier les changements.
• Command : encapsule une requête sous forme d’objet.
• Chain of Responsibility : passe une requête le long d’une chaîne d’objets jusqu’à ce qu’elle soit traitée.
• Template Method : définit l’ossature d’un algorithme et laisse certaines étapes aux sous-classes.
• State : permet à un objet de changer de comportement lorsque son état change.
• Mediator : centralise la communication entre objets pour réduire les dépendances directes.
• Iterator : permet d’accéder séquentiellement aux éléments d’une collection sans exposer sa structure interne.
• Visitor : permet de séparer un algorithme de la structure sur laquelle il opère.

 

5          Exemples

5.1        Singleton

Le patron Singleton garantit qu’une classe n’a qu’une seule instance et fournit un point d’accès global à cette instance. Il est particulièrement utile lorsque l’on souhaite contrôler l’accès à une ressource partagée, comme une connexion à une base de données ou un gestionnaire de configuration. Le Singleton empêche la création multiple d’objets de la classe, ce qui assure une cohérence des données et évite des problèmes liés à la duplication des ressources.

public class Singleton {     private static Singleton instance;       private Singleton() {}       public static synchronized Singleton getInstance() {         if (instance == null) {             instance = new Singleton();         }         return instance;     } }

 

 

5.2        Strategy

Le patron Strategy définit une famille d’algorithmes, encapsule chacun d’eux et les rend interchangeables. Il permet ainsi de séparer le comportement d’un objet de sa structure, offrant la possibilité de changer dynamiquement l’algorithme utilisé sans modifier le code de l’objet client. Ce pattern est utile pour gérer des variations de comportements ou d’algorithmes, comme différentes méthodes de tri, de calcul de tarif ou de traitement de paiement.

public interface DeliveryStrategy {     double calculate(double distance); }

public class StandardDelivery implements DeliveryStrategy {     @Override     public double calculate(double distance) {         return distance * 1.0; // tarif standard     } }   public class ExpressDelivery implements DeliveryStrategy {     @Override     public double calculate(double distance) {         return distance * 2.0; // tarif express     } }

 

5.3        Composite

Le patron Composite permet de traiter de manière uniforme des objets simples et des objets composés (agrégations d’objets). Il est particulièrement adapté aux structures hiérarchiques, comme des arbres de composants graphiques ou des systèmes de fichiers. Grâce au Composite, les clients peuvent manipuler un objet individuel ou un groupe d’objets de la même manière, ce qui simplifie le code et facilite l’extension des structures complexes.