Introduction aux Design Patterns

Les Design Patterns

• Les design patterns sont des solutions standardisées et efficaces pour résoudre des problèmes courants en conception orientée objet.
• Ces solutions prennent la forme de modèles de classes.
• Un patron n'est pas un code spécifique, mais un concept général pour résoudre un problème précis.
• Le but est de suivre le principe du patron et d'implémenter une solution adaptée au programme concerné.
• Les design patterns sont des modèles abstraits avec un objectif et une structure de classes reproductibles dans divers contextes.

Objectifs des Design Patterns

• Faciliter la conception (modèles de classes et architectures).
• Réutiliser des classes et du code.
• Faciliter l'évolution de la conception.
• Obtenir une implémentation efficace et pratique.

Historique des Design Patterns

• Le concept a été décrit par Christopher Alexander dans "A Pattern Language: Towns, Buildings, Construction".
• L'ouvrage invente un "langage" pour concevoir un environnement urbain, utilisant des patrons pour indiquer des éléments comme la hauteur des fenêtres ou le nombre d'étages.
• L'idée a été reprise dans la programmation orientée objet par Erich Gamma, John Vlissides, Ralph Johnson et Richard Helm.
• Ces 4 auteurs, connus sous le nom de "Gang of Four" (GoF), ont formalisé les design patterns en 1994.
• Leur livre "Design Patterns : elements of reusable software" contient 22 patrons résolvant des problèmes de conception orientée objet et est rapidement devenu un best-seller.

Classification des Design Patterns

• Il existe 22 design patterns du GoF répartis en trois catégories.

Patrons de création (creational patterns)

• Ils concernent les mécanismes de création de classes et d'objets pour augmenter la flexibilité et la réutilisation du code.
• Les patrons de cette catégorie sont : Singleton, Factory, Abstract factory, Builder, Prototype

Singleton

• Garanti qu'une seule instance d'une classe est créée, fournissant un accès global à cette instance.
• Permet de garantir une instance à la fois d'une classe à un instant T à l'exécution (fournit ainsi un accès global à cette instance).

Fabrique (Factory Method)

• Définit une interface pour créer des objets dans une classe mère.
• Délègue aux sous-classes le choix du type d'objet à créer.
• Permet de créer des familles d'objets dont le type est déterminé à l'exécution.

Fabrique Abstraite (Abstract Factory)

• Permet de créer des familles d'objets liés sans spécifier leurs classes concrètes.
• Est une généralisation du modèle de fabrique simple.

Monteur (Builder)

• Simplifie la création d'objets complexes en séparant le processus de construction de l'objet du résultat final.
• L'objet est construit étape par étape, avec uniquement les attributs nécessaires.

Prototype

• Permet de créer de nouveaux objets à partir d'objets existants sans dépendre de leur classe.
• Utilise une méthode de clonage pour copier les objets, puis apporte les modifications nécessaires.
• Permet de gagner du temps lors de la création d'objets similaires.

Patrons de structure ou structurels (structural patterns)

• Ils concernent l'assemblage des objets et des classes en de plus grandes structures, tout en maintenant la flexibilité et l'efficacité.
• Les patrons de cette catégorie incluent : Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy.

Adaptateur (Adapter)

• Permet de faire collaborer des objets avec des interfaces incompatibles.

Pont (Bridge)

• Permet de séparer l'abstraction d'une classe de son implémentation.
• Le pont sert de lien entre les deux parties, permettant leur évolution indépendante.

Composite

• Permet de créer une arborescence d'objets sous forme de structure en arbre (nœud/feuille).
• Permet de manipuler un élément, une branche ou l'ensemble de l'arbre de la même manière.

Décorateur (Decorator)

• Permet d'ajouter dynamiquement des comportements supplémentaires à un objet en l'enveloppant dans des décorateurs.

Façade (Facade)

• Fournit une interface simplifiée pour accéder à un sous-système (ensemble de classes), une librairie ou un framework.

Poids Mouche (Flyweight)

• Permet d'utiliser un type d'objet pour représenter une gamme de petits objets tous différents (pour réutiliser ce type d'objet).

Procuration (Proxy)

• Fournit un substitut d'un objet, permettant de contrôler l'accès à l'objet original et d'effectuer des manipulations avant ou après la demande.

Patrons de comportement (behavioral patterns)

• Ils concernent le comportement des objets de classes dans les algorithmes, notamment leur communication et répartition des responsabilités.
• Les patterns de cette catégorie incluent : Chain of Responsibility, Command, Iterator, Mediator, Observer, Strategy, State, Memento, Template method, Visitor.

Stratégie (Strategy)

• Définit une famille d'algorithmes et permet de les utiliser de manière interchangeable en fonction du contexte.

État (State)

• Permet de modifier le comportement d'un objet en fonction de son état interne.
• Souvent utilisé pour implémenter un système à états.

Itérateur (Iterator)

• Permet de parcourir les éléments d'une collection sans révéler sa représentation interne (liste, pile, arbre, etc.).

Médiateur (Mediator)

• Diminue les dépendances entre les objets en restreignant les communications directes et en forçant la collaboration via un objet médiateur.

Mémento (Memento)

• Permet de sauvegarder et de restaurer l'état précédent d'un objet sans révéler les détails de son implémentation.

Observateur (Observer)

• Permet de mettre en place un mécanisme de souscription entre un objet observé (le sujet) et un objet qui a besoin d'être tenu informé des changements (l'observateur).

Patron de méthode (Template Method)

• Simplifie l'écriture d'algorithmes complexes en définissant le squelette d'un algorithme dans une méthode d'une classe mère et en laissant les sous-classes redéfinir certaines étapes de l'algorithme.

Chaîne de responsabilité (Chain of Responsibility)

• Permet de faire circuler les requêtes à travers une chaîne de gestionnaires. Si un gestionnaire ne peut pas traiter la requête, il la transmet au suivant.

Commande (Command)

• Transforme une requête en un objet autonome contenant toutes les informations nécessaires pour exécuter l'action. Ceci permet de mettre les commandes en file d'attente, de les annuler, etc.

Visiteur (Visitor)

Ce modèle de conception permet d'ajouter de nouvelles opérations aux classes existantes sans modifier leur structure, en utilisant une classe “visitante”.

Pourquoi utiliser les design patterns

• Les design patterns fournissent une boîte à outils de solutions fiables et éprouvées pour les problèmes de conception orientée objet classiques.
• Ils définissent un langage commun compréhensible par tous les développeurs, facilitant la communication et la documentation.

Singleton: objectif

• Permet d'obtenir une seule et unique instance d'une classe avec une méthode pour obtenir une instance unique et un mécanisme pour empêcher la création d'autres instances.

Singleton: Recommandations à l'implémentation (en Java)

• L'attribut singleton de la classe Singleton est déclaré en static pour stocker une instance unique en mémoire.
• Le constructeur de la classe doit être private.
• On déclare un getter static pour renvoyer l'instance ou la créer (getInstance()).
• La classe est déclarée en final (car un singleton n'est pas censé avoir d'héritier).
• En cas de multithread, il faut s'assurer qu'un seul objet sera créé. En Java : on utilise synchronized à l'instanciation (empêche l'instanciation multiple même par différents threads).

Singleton: utilités

• Le singleton garantit l'unicité d'une instance pour une classe, utile pour contrôler l'accès à des données ou ressources partagées. Son fonctionnement est le suivant : on créé un objet et il est unique dans l'application.
• Si des clients veulent manipuler le même objet, on ne pourra pas en créer un nouveau, on va plutôt récupérer celui qui existe déjà.
• On notera qu'il est impossible d'implémenter ce comportement avec un constructeur normal (public), puisqu'un constructeur doit théoriquement toujours retourner un nouvel objet.
• Le singleton permet d'accéder à l'objet comme une variable globale, offrant un point d'accès global à une instance de classe.
• Exemples d'utilisation : classes de configuration, accès à des ressources partagées, gestion des logs.

Singleton: Points forts

• garantit l'unicité de l'instance de la classe.
• on obtient un point d'accès global à l'instance.
• l'objet du singleton est uniquement initialisé la première fois qu'il est appelé.

Singleton: Points faibles

• Il doit bénéficier d'un traitement spécial pour fonctionner dans un environnement multithread afin que le singleton ne se retrouve pas en plusieurs exemplaires.
• Les tests unitaires peuvent se révéler difficiles.

Fabrique (fabrique) : objectif

• Permet de créer des familles d'objets à partir de types abstraits en séparant la création d'objets de leur utilisation.
• L'objet retourné par la fabrique est toujours du type de la classe mère, mais les traitements exécutés sont ceux de l'instance spécifique.
• L'atout principal est de créer des objets sans exposer la logique au client, puis de faire référence à ces objets via une classe commune.

Fabrique (fabrique) : Utilité

• Le client ne peut déterminer le type d'objet à créer qu'à l'exécution.
• La fabrique effectue une séparation entre le code du constructeur et le code qui utilise réellement le produit.
• Le code du constructeur devient ainsi plus évolutif et indépendant du reste du code.

Fabrique (fabrique) : Points forts

• Séparation des méthodes de création d'objets des méthodes de leur utilisation.
• Principe de responsabilité unique : le fait d'avoir tout le code de création des produits au même endroit permet une meilleure maintenabilité.
• Evolutivité: on peut ajouter de nouveaux types de produits dans le programme sans endommager l'existant.
• La fabrique est une spécialisation du patron de méthode (template method), et peut y être intégrée.

Fabrique (fabrique) : Points faibles

• Le code peut devenir plus complexe puisqu'on peut introduire de nombreuses sous-classes pour la mise en place du design pattern.
• Pour pouvoir utiliser ce patron correctement dans du code existant, il est préférable d'avoir déjà une hiérarchie existante de classes de création (fabrique).

Builder (Monteur): objectif

• Permet de simplifier la création d'objets complexes avec un constructeur complexe en créant les objets étape par étape avec uniquement les paramètres nécessaires.

Builder (Monteur): Les classes impliquées dans ce modèle

• Builder: La classe de base du monteur qui définit toutes les étapes communes de la construction.
• ConcreteBuilder: Les monteurs concrets implémentent les étapes pour construire les représentations particulières du produit.
• Director: Le directeur s'occupe de gérer l'ordonnancement des différentes étapes de construction.
• La classe directeur se révèle idéale pour y placer les routines de construction et pouvoir les réutiliser ensuite dans le programme.

Builder (Monteur): utilités

Ce patron est utile quand :

• On veut éviter un constructeur complexe avec des paramètres souvent peu utilisées.
• On peut ainsi créer des objets par étape et utiliser les étapes qui sont nécessaires

Builder (Monteur): points forts

• Découplage du code complexe de création de la logique métier du produit(moins de surcharge côté constructeur de classe)
• On réutilise le code de construction lors que l'on createdifférentesreprésentations de produits qui ont même processus de construction

Prototype: objectif

• Permet d'obtenir des copies d'objets de manière rapide, notamment quand beaucoup d'objets similaires doivent être créés avec quelques changements seulement.
• On utilise pour cela une classe prototype avec une méthode de clonage.

Prototype : Les classes impliquées dans ce modèle

• Prototype: est une classe abstraite (ou interface) qui sert de modèle principal pour la création de nouvelles copies.
• ConcretePrototype: spécialise la classe Prototype et permet de modifier certains attributs.

Le modèle Adapter

• Permet de faire collaborer des classes dont les interfaces sont incompatibles
• Il sert d'intermédiaire pour adapter une classe à une autre.

Le modèle Adapter : Utilité

• L'adaptateur(Adapter) est utile lorsque l'on veut que des classes incompatibles collaborent ensemble
• Il peut être utilisé pour mieux gérer l'évolution de la conception d'une application quand cela est nécessaire ou encore de permettre à des classes incompatibles de pouvoir collaborer.

Le modèle Composite : objectif

• Créer une structure arborescentede d'objets et de les manipuler de la même manière
• Interface commmune appelée composant qui réunit tous les sous-éléments

Le modèle Le pattern Bridge (Pont) : objectif

• Servir de pont entre deux représentations, l'une abstraite et l'autre concrète
• Séparer l'abstraction et l'implémentation qui varient l'une de l'autre

Le modèle Le pattern Decorator (Décorateur); objectif

• Faciliter l'ajout de comportements supplémentaires à des objets de classes( altérer le code source)
• Définir une classe décorateur qui enveloppe la classe d'origine et qui va fournir les comportements supplémentaires

Façade (Façade) : objectif

• Définir en interface simplifiée pour interagir avec un ensemble de classes par le client
• Faite pour maitriser ces mêmes librairies et en limiter certains accès

Patrons de comportement: objectif ( Strategy (stratégie))

Le pattern concerne la sélection de comportements différents employés par une même classe en fonction des besoins

Points forts pour commader des objets :Le patron Commande

• permet aux objets de commmander des actions sans vraiment savoir à quoi s'attendre
• permet d'assigner des actions précises avec des paramètres différents

Pattern observer : but

Notitfier aux observateurs ( objtects observés ) par l'objet observé

Points forts du pattern observer

• on peut aouter ou enlever un observateur sns trop changer la logique ou la structure du code

iterateur lequsel but ?

iterateur est essentiellement un access pour tous les objets et ses elements sans en éxposer la logique

L'iterator peut

cacher les implémentations sur les iterateurs en eux même , garder les détails cachés ou impliqués pour rendre le code plus lisible Peut supporter une variété de types de façon à ce que le client en fasse ce qu'il souhaite, l'itrérateur lui renvoie quand même les données

Objectif : template method

Ce design pattern permet de simplifier l'écriture d'algorithmes complexes qui ont beaucoup d'étapes dont des étapes de bases, des étapes facultatives et/ou des étapes qui changent selon les situations

Points forts template method

Le client définit dynamiquement le contenu de certaines étapes d'un algorithme complexe Reutulisatiion facile

points faibles template method

Le client ne peut pas dynamiquement changer les étapes de l'algorithme.

architecture MVC

code de plus clair et facile a lire et a maintain