Vous êtes sur la page 1sur 21

factory

Définition
Le design pattern factory fournie un mécanisme pour utiliser une instance comme une usine à
objet. Le factory peut retourner une instance d’un objet parmi plusieurs types (ordonnées dans
une relation d’héritage), en fonction des données qu’on lui fournit

Quand l’utiliser
 Quand une classe ne peut pas anticiper quel type d’objet elle doit créer
 Quand on veut rendre local la connaissance de quelle classe doit être créée
 Quand on a des classes qui héritent d’une même classe mère ou même des classes
indépendantes qui partagent la même interface. Ainsi les méthodes dans ces classes
sont les mêmes et peuvent être interchangeables
 Quand on veut isoler le client du type actuel de classes qui est en train d’etre instancié

Bénéfices
Le client n’a pas besoin de connaitre chaque classe fille des objets qu’il doit créer, il a besoin
juste d’une référence à la classe abstraite ou interface et l’objet factory
Le factory encapsule la création d’objets, ceci peut être utile lorsque le processus de création
est très complexe.

Conséquences/retombées
Il n’y pas d’autre moyen de changer l’implémentation d’une classe sans une recompilation
totale.
Abstract Factory
Définition
Une factory abstraite est un pattern créationnel qui est relié au pattern factory, en lui rajoutant
une nouvelle couche d’abstraction. Ce qui veut dire que ce pattern encapsule un groupe de
classes factory individuelle (à l’opposé du factory qui a des méthodes abstraites dérivées dans
les classes filles) qui partagent des interfaces communes.
Le client utilise l’abstract factory qui fournit une interface pour créer des familles d’objets liés
ou dépendants sans spécifier leurs classes concrètes. Ce pattern sépare les détails
d’implémentation d’un jeu d’objets de son utilisation en général.

Quand l’utiliser
Ce pattern peut être utilisé quand on doit créer un jeu d’objets qui partagent le même thème,
et ou le client a juste besoin de savoir comment gérer l’équivalent abstrait de cet objet, comme
lorsque l’implémentation n’est pas importante pour le client, ou le cas où il a juste besoin de
traiter certains attributs en se souciant de leur signification et non de leur contenu. L’abstract
factory est surtout utilisée lorsqu’il y a un besoin d’utiliser différents types d’objets et ou les
objets peuvent être ajoutés ou changés durant le cycle de vie d’exécution d’une application

Bénéfices
L’utilisation de ce pattern rend les classes concrètes interchangeables sans changer le code qui
les utilise, même durant l’exécution de l’application les objets peuvent être intervertis

Conséquences/retombées
Comme pour les design patterns similaires l’inconvénient majeur est l’introduction d’une
nouvelle complexité parfois non nécessaire, et le travail supplémentaire que ça implique pour
arriver à créer tout simplement une instance.
Builder
Définition
Le pattern builder peut être utilisé pour faciliter la construction d'objets complexes depuis des
objets simples.
Il sépare la construction d'objets complexes de leurs représentations ainsi le même processus
de construction peut être utilisé pour construire des objets similaires.
Les patterns reliés sont Abstract factory et composite

Quand l'utiliser
 Quand l'algorithme de création d'objets doit être indépendant des fragments
constituants l'objet et comment ils doivent être assemblés
 Quand le processus de construction doit permettre plusieurs représentations de l’objet
construit
 Quand on veut empêcher les clients de connaitre le processus de création et/ou le
résultat produit

Bénéfices
 Le produit construit est indépendant des détails de sa construction
 Le code de construction est isolé du code de la représentation et chacun est facilement
remplaçable/modifiable sans toucher à l’autre
 Permet d’avoir un contrôle sur le processus de construction
 Permet de réutiliser et/ou de changer le processus et/ou le produit indépendamment.

Conséquences/retombées
 Nécessite une grande flexibilité pour la création d’objets complexes varies.
 Nécessite la création d’objets complexes et d’agrégats d’objets
Prototype
Définition
Le pattern prototype est d’une façon basique la création de nouvelles instances par le clonage
d’instances existantes, en créant un prototype les nouveaux objets sont tout simplement crées
par copie du prototype

Quand l’utiliser
 Quand un système nécessite une indépendance vis-à-vis de la création de nouveaux
objets, composés et représentés.
 Quand on veut rajouter et enlever des objets d’une façon dynamique au runtime
 Lorsque on peut spécifier de nouveaux objets en changeant simplement les objets
existants
 Quand on configure une application avec des classes d’une façon dynamique
 Quand on veut réduire le nombre de classes dans un système au minimum
 Lorsque la gestion d’états d’une population d’instance est difficile, couteux, ou
exclusif

Bénéfices
 Augmente les performances lors de la création d’objets volumineux, de classes
chargées dynamiquement
 Réduit les héritages, les classes filles

Conséquences/retombées
Chaque classe héritant ou dérivant du prototype doit implémenter la méthode Clone. Ceci
peut être difficile avec des classes existantes, avec des objets internes aux références
circulaires (un objet en appelant un autre … etc appelant un autre appelant le tout premier
objet), ou qui ne supportent pas la copie.
Singleton
Définition
Le pattern singleton permet la possibilité de contrôler un nombre d’instance (le plus souvent
une seule) qui peuvent être fabriquées, on aura en même temps un point d’accès globale à ces
instances.

Quand l'utiliser
Quand une seule instance ou un nombre spécifique d’instances d’une classe sont autorisés, les
objets façades sont souvent des singletons parce qu’une seule façade est requise.

Bénéfices
 Un accès contrôlé à une instance unique
 Réduit l’espace de nom (l’espace commun des variables globales)
 Permet le raffinement des opérations et des représentations

Conséquences/retombées
Le pattern singleton est considéré par certains comme un anti-pattern (une mauvaise habitude
de conception), à cause d’une surutilisation, d’une limitation non nécessaire pour l’utilisation
d’une seule instance d’une classe alors qu’on n’en a pas besoin.
Adapter pattern
Définition
Le design pattern adapter est utilisé pour transformé une interface d’une classe en une autre
interface. Ceci implique qu’on peut faire que des classes peuvent travailler ensemble alors que
c’était impossible avant à cause d’une incompatibilité de leurs interfaces.
Une classe adaptateur utilise des héritage multiple (en étendant une classe et/ou en
implémentant une ou plusieurs classes) pour adapter une interface à une autre. Un objet adaptor
est relié à l’agrégation d’objets.

Quand l’utiliser
 Quand on veut utiliser une classe existante et que son interface ne convient pas à nos
besoins
 Quand on veut créer une classe réutilisable qui coopère avec des classes non liées ou
non visibles, ou des classes qui ont des classes incompatibles.
 Lorsqu’on veut augmenter la transparence d’une classe
 Lorsqu’on veut faire un kit pluggable

Bénéfices
 Une classe hautement réutilisable
 Permet de rajouter uniquement un seul objet

Conséquences/retombées
Lorsqu’on utilise java, la cible doit être une interface
Bridge
Définition
Découple une classe abstraite ou une interface de son implémentation, ainsi les deux peuvent
évoluer indépendamment. Le design pattern Bridge trace une ligne de démarcation entre une
classe abstraite et son implémentation

Quand l'utiliser

 Lorsqu’on veut séparer une structure abstraite et son implémentation concrète


 Lorsqu’on veut partager une implémentation entre plusieurs objets
 Lorsqu’on veut réutiliser les ressources existantes en un mode « facile à étendre » (offrir
un produit qui est facilement configurable au niveau des classes métier par exemple)
 Lorsqu’on veut cacher les détails de l’implémentation aux clients. Un changeme nt
d’implémentation ne devrait pas avoir d’impact sur les clients.

Bénéfices

 L’implémentation peut être sélectionnée ou changée lors de l’exécution dans le


runtime.
 L’abstraction et l’implémentation peuvent être étendues ou composées avec d’autres
classes indépendamment l’une de l’autre

Conséquences/retombées

Une double redirection. Par exemple les méthodes implémentées par une classes filles d’une
API de dessin graphique. Les classes contrôleurs doivent déléguer les messages à une classe
fille d’une API de dessin, qui implémente la méthode appropriée. Ceci peut avoir des
conséquences sur les performances, car la pile d’appel des méthodes s’en trouve allongée.

Composite
Définition
Le pattern composite peut nous aider à créer des structures en forme d’arbre sans nous obliger
à différencier entre les branches et les feuilles au regard de l’usage, comme c’est le cas de linux
ou tout est fichier, même les dossiers, qui sont des conteneurs d’autres fichiers. Ce pattern nous
assure que le client va traiter les objets individuels et la composition des objets d’une façon
uniforme.

Quand l'utiliser
 Lorsqu’on veut représenter une structure en arbre
 Lorsqu’on veut rendre le code indifférent à la différence entre une feuille et une branche
(une composition de feuilles)
 Lorsque la structure peut avoir un degré de complexité inconnu au départ et/ou est
dynamique

Bénéfices
 Définie une hiérarchie de classes consistante en des objets primitifs et des objets
composites
 Facilite l’ajout de nouveaux types de composants.

Conséquences/retombées
Le pattern composite nous assure une facilité à ajouter de nouveaux genres de composants à
des collections du moment qu’elles supportent une interface de programmation similaire. D’un
autre coté ceci à l’inconvénient de rendre le système trop généraliste. Il se peut qu’il soit diffic ile
de rendre le système restreint à certaines classes lorsque celui-ci doit l’être.
Decorator
Définition
Le pattern decorator peut nous laisser attacher des responsabilités additionnelles à une classe et
modifier ses fonctionnalités dynamiquement. Le decorator fournit une alternative à l’hérita ge
pour étendre des fonctionnalités, en utilisant la composition à la place de l’héritage.

Quand l'utiliser
 Quand on veut ajouter des responsabilités à des objets individ uels dynamiquement et
d’une façon transparente, sans affecter l’objet original ou d’autres objets.
 Lorsqu’on veut ajouter des responsabilités à un objet, responsabilités qui vont changer
dans le futur
 Lorsque l’extension par l’héritage classique est impraticable.

Bénéfices
 Plus de flexibilité qu’un héritage classique
 Simplifie le développement, parce qu’on écrit une série de classes spécifiques aux
fonctionnalité au lieu de rajouter les fonctionnalités à chaque classe, avec les différentes
combinaisons possibles de fonctionnalités
 Augmente la robustesse des objets, leurs capacités à être étendues parce qu’on code en
rajoutant de nouvelles classes et non en modifiant les existantes

Conséquences/retombées
Ce qu’on doit avoir en tête lorsqu’on implémente le pattern decorator est qu’on doit simplifier
l’interface le plus possible. Rendre l’interface complexe rend l’application des decorators
fastidieuse.
Un autre inconvénient est lorsqu’on utilise une série de décorateur, ceci peut avoir des impacts
sur les performances.
Le tout dernier inconvénient est que le type de l’objet décoré est uniquement le dernier
décorateur qu’on lui a appliqué, on n’a de visibilité ni sur la série de décorateurs, ni sur l’objet
originel.
FACADE
Définition
Ce design pattern fourni une interface unifiée a un ensemble d’interfaces dans un sous-système.
Il définit une interface de haut niveau qui permet une utilisation plus aisée du sous système
Une façade est un objet qui fournit une interface simplifiée à de grandes parties de code, comme
les classes bibliothèques.

Quand l'utiliser
Le design pattern façade peut être utilisé pour alléger l’utilisation d’une bibliothèque logicie lle,
en offrant des méthodes lisibles pour les taches courantes. Pour la même raison, il rend le code
beaucoup plus lisible.
Le même pattern peut être utilisé pour réduire la dépendance au code externe lorsqu’on travaille
à l’intérieur d’une bibliothèque pour construire de nouvelles méthodes ou pour encapsuler les
objets dont on a besoin dans des méthodes plus simples à invoquer, et ce dans la plupart des
langages qui offrent cette possibilité là, ce qui nous permet plus de flexibilité lorsqu’on
développe un système.
Un dernier cas de figure consiste à encapsuler une API très mal adaptée au besoin ou très
pauvre, ou très mal conçue pour la rendre plus robuste ou plus apte à nos besoins.

Bénéfices
Le bénéfice principal de ce design pattern est de pouvoir combiner des appels de méthodes
complexes et des blocs de code en une seule méthode qui va effectuer une tâche complexe et
récurrente. En plus de rendre le code plus facile à utiliser et à comprendre, il réduit les
dépendances entre les différentes librairies ou packages, rendant ainsi les développeurs plus
aptes à envisager des alternatives avant d’écrire un nouveau code qui va exposer le travail
interne qui se fait au niveau du package. Aussi depuis lors qu’une façade rend le couplage entre
le code client et les autres paquages ou bibliothèques faible, elle nous permet de changer les
composants internes que le client n’appelle pas directement.

Conséquences/retombées
La conséquence logique quand on masque ce qui se passe en dessous d’une façade est qu’on a
moins de contrôle sur ce qui s’y passe réellement, Aussi lorsqu’une classe requiert une variatio n
minime d’une implémentation d’une méthode d’une façade, on peut se retrouver en face d’un
problème assez complexe.
Flyweight
Définition
Le flyweight (littéralement poids plume) fournie un mécanisme avec lequel on évite la création
d’un nombre élevé d’objets « couteux », à la place on réutilise les instances déjà existantes pour
représenter des nouvelles.

Quand l'utiliser
 Lorsqu’il y a un grand nombre d’objets qui peuvent ne pas tenir tous en mémoire
 Lorsque la majeur partie d’un objet peut être stockée sur un disque ou calculée par le
runtime
 Lorsqu’il y a des groupes d’objets qui peuvent partager un état
 Lorsque le statut de l’objet peut être factorisé dans un nombre relativement réduit
d’objets avec un state partagé

Bénéfices
Réduit le nombre d’objets crées, réduit l’empreinte sur la mémoire et accroit les performances

Conséquences/retombées
Le design des objets très proches aux couches les plus profondes du système en terme de
granularité assure une flexibilité optimale, mais peut très facilement devenir couteux en terme
de performance et d’utilisation mémoire contrairement au but escompté.
PROXY
Définition
Le proxy est un pattern structurel qui assure un contrôle d’un autre objet, au niveau de
l’utilisation comme au niveau du contrôle d’accès.

Quand l'utiliser
 Lorsque la création d’un objet est relativement couteuse, une bonne idée est de le
remplacer avec un proxy qui va rendre l’institution aussi minimale que possible.
 Ce pattern permet des vérifications (par exemple sur les noms d’utilisateurs, ou sur les
autorités) avant de solliciter l’objet contrôlée pour vérification
 Peut être utilisé pour représenter localement un objet distant.

Bénéfices
Donne la possibilité de contrôler l’accès à un objet, soit pour des raisons de cout, soit pour des
raisons de sécurité.

Conséquences/retombées
Rajoute un nouveau niveau d’abstraction pour un objet donné, si certains objets accèdent à
l’objet cible directement d’autre via le proxy, il y a des chances pour qu’ils aient différents
comportements ou représentations d’un même objet, ceci peut être voulu par le concepteur,
mais parfois ceci peut poser problème au développeur.
Chain-of-responsibility
Définition
Ce design pattern permet qu’une requête soit interceptée et traitée par plusieurs objets sans que
l’un d’eux ait connaissance des autres. On évite ainsi le couplage entre un émetteur et les
récepteurs possibles. On place tous les récepteurs dans une chaine qui permet aux objets
récepteurs de passer la requête au récepteur suivant jusqu’à ce que l’un des récepteurs traite la
requête ou que la fin de la chaine soit atteinte.

Quand l’utiliser
 Quand on veut que plusieurs objets (plus qu’un) interceptent une requête, mais qu’on
ignore lequel exactement va le faire.
 Quand on veut envoyer une requête à un de plusieurs objets, sans connaitre lequel
exactement.
 Quand l’ensemble des objets qui doivent traiter une requête doit être spécifié
dynamiquement ou qu’il va changer durant l’exécution de l’applicatio n.

Bénéfices
 Il réduit le couplage
 Il augmente la flexibilité lorsqu’on traite une requête (handling)

Conséquences/retombées
La réception n’est pas garantie vu qu’une requête n’a pas un récepteur explicite, il n’y a pas de
garantie qu’elle soit traitée sauf si la chaine est configurée correctement.
command
Définition
Le pattern command est utilisé pour créer des objets qui représentent des actions et des
évènements dans une application. Un Objet de type command encapsule une action ou un
évènement et contient toutes les informations nécessaires pour comprendre exactement ce qui
s’est passé. En passant l’objet command comme paramètre permet, à n’importe quel endroit,
d’extraire les informations à propos des actions et des évènements arrivés.

Quand l’utiliser
 Lorsqu’on veut une action qui peut être représentée par plusieurs façons, comme un
menu dropdown, un boutton ou un menu popup
 Lorsqu’on veut créer une fonctionnalité undo/redo

Bénéfices
 Un objet de type command est un lieu de stockage possible des paramètres des
procédures. Il peut être utilisé lorsqu’on rassemble les paramètres pour un appel d’une
fonction et permet de mettre de côté le command pour une utilisation ultérieure.
 Une classe est endroit approprié pour collecter du code et des données relatives à
certaines actions ou évènements.
 Il permet à une réaction au command d’être exécutée après un certain temps qu’il soit
arrivé
 Les objets command permet d’avoir des structures de données contenant des
commandes multiples
 Les objets de type command permettent d’avoir des opérations réversibles (undo), par
le biais d’objets command stockés (dans une liste chainée dynamique par exemple)

Conséquences/retombées
Le plus gros inconvénient de ce pattern est la prolifération de petites classes qui surchargent le
programme. Ceci dit, même si on se retrouve dans le cas où on a des évènements de clicks
séparés, on appelle habituellement des méthodes privées assez courtes pour effectuer les
fonctions actuelles, ce qui revient au même. Ces petites méthodes ont les mêmes inconvénie nts
que nos classes. Bâtir une classe Command ou écrire plus de méthodes ont le même degré de
complexité, la plus grande différence est que lorsqu’on utilise le pattern Command produit de
petites classes et non de grandes classes avec des petites méthodes, ce qui rend le code beaucoup
plus lisible.
Iterator
Définition
Le design pattern iterator fournit un moyen d’accéder aux éléments d’un agrégat d’objet (une
collection), d’une façon séquentielle, sans exposer les mécanismes internes de stockage et de
représentation.
.

Quand l'utiliser
A utiliser lorsqu’on souhaite un accès séquentiel a un agrégat d’objets.
Les java collections comme ArrayList et HashMap ont implémenté ce design pattern.

Bénéfices
 Le même iterator peut être utilisé pour différents agrégats
 Permet de parcourir l’agrégat en plusieurs sens, en fonction des besoins
 Encapsule la structure interne du comment l’itération se produit
 Ne bloque pas les classes pour des opérations données lorsqu’on veut parcourir l’agrégat
en même temps qu’on effectue une opération sur un élément de l’agrégat par exemple.

Conséquences/retombées
Si l’iterator n’est pas robuste, il ne peut pas être considéré comme fiable lorsqu’on travaille
avec le multi-threads (problemes de synchronisation). Pour pallier à ce problème l’iterator doit
permettre l’insertion et la suppression par des méthodes synchronisées, si cela est impossible à
réaliser il faut travailler avec un memento qui doit sauvegarder l’état de l’iterator
Mediator
Définition
Avec le Pattern mediator, les communications entre objets est encapsulée dans un objet appelé
mediator. Les objets ne communiquent plus chacun avec l’autre, mais communiquent avec (et
via) uniquement le mediator. Le résultat est une implémentation plus cohérente de la logique et
un couplage plus lâche entre les objets.

Quand l’utiliser
Le pattern Mediator peut être utilisé lorsque des objets d’un même ensemble communiquent de
manière bien définie mais complexe, les interdépendances qui en résultent seront non
structurées et difficiles à saisir. S'il est difficile de réutiliser un objet car il se réfère à de
nombreux objets et/ou communique avec eux, ce modèle est une bonne solution.
Les identités des objets communicants seront protégées lorsqu’on utilise le pattern Mediator
qui est un bon moyen lorsque la sécurité est importante.
En plus si on souhaite personnaliser un comportement qui se répartie entre plusieurs classes
sans avoir recours à plusieurs sous-classes ce pattern peut être utilisé.
Ce pattern est utilisé dans plusieurs systèmes qui travaillent sur les protocole d’envoi et de
réception, comme les listes de diffusions, ou les serveurs de tchat.
Un autre domaine d’application est les interfaces utilisateurs (GUI) où le Mediator peut
encapsuler un comportement collectif à contrôler et coordonner les interactions d’un groupe de
widgets d’une GUI. Le Mediator sert d’intermédiaire qui permet aux objets du groupe de
coopérer/communiquer sans se référer l’un à l’autre explicitement. Tous les objets ne
connaissent que le mediator et se réfèrent à lui, ce qui limite le nombre d’interconnexions.

Bénéfices
Le mediator a cinq avantages et retombées principales :
 Limiter les héritages, du moment que le mediator s’occupe du comportement qui
normalement devrait être distribué sur les objets. Changer ce comportement ne requiert
plus de faire une classe fille pour chaque objet, mais de créer une classe fille pour le
mediator.
 Les classes autres que le mediator sont découplées les unes des autres, ce qui nous
permet de les réutiliser à souhait, si on désire changer le comportement en gardant la
même interface par exemple il suffit d’adresser le composant graphique à un autre
mediator.
 Mediator simplifie le protocole de communication entre objets. Du moment qu’il
remplace le protocole d’interaction many-to-many par un protocole one-to-many qui est
un protocole plus facile à comprendre, maintenir et développer.
 Le mediator rend la coopération entre objets abstraite. Le mediator nous permet de nous
concentrer sur comment les objets interagissent séparément de leur propre
comportement, ce qui rend le « comment les objets interagissent dans le système » plus
facile à comprendre.
 Un contrôle centralisé est réalisé en déplaçant la complexité des interactions et en la
concentrant dans le mediator. Le mediator encapsule les protocoles et peut devenir
beaucoup plus complexe que les autres objets du groupe. Ceci peut rendre le mediator
très complexe et difficile à maintenir.

Conséquences/retombées
Au-delà des bénéfices et des conséquences citées dessus. Une retombée important est que le
mediator peut avoir des impacts sur les performances du système, du moment que toutes les
communications passent par un ou plusieurs mediators, il peut devenir un goulot
d’étranglement.
Memento
Définition
Ce pattern est utilisé pour enregistrer l’état interne d’un objet sans violer le principe
d’encapsulation et de le consulter ultérieurement sans que l’objet originel n’en ait connaissance.
Un memento est un objet qui stocke une capture (snapshot) de l’état (state) interne d’un autre
objet.

Quand l’utiliser
 Quand on veut que certains informations d’un objet soient disponibles pour un autre
objet
 Quand on veut créer des snapshots de l’état d’un autre objet
 Lorsque on veut refaire/annuler (redo/undo) des fonctionnalités ou des opérations

.
Bénéfices
La possibilité de restaurer un objet à un état antérieur.

Conséquences/retombées
Lorsqu’on utilise le memento, il faut faire attention à ce que l’objet generator (l’objet origina l)
peut changer d’autres objets ou ressources, le memento opère sur un seul objet.
Un autre point est la taille des informations stockées par l’objet generator. Ceci peut être très
couteux si le client crée et retourne des mementos fréquemment
Observer
Définition
Le pattern Observer est un pattern structurel qui permet la fonctionnalité de
publication/souscription. Ceci est accompli par un objet autonome, un publicateur qui autorise
les autres objets à souscrire ou se désinscrire à souhait. Le pattern n’impose pas de limite quant
au nombre d’observateurs ayant souscrit, ou désinscrit, eux même pour notification des futurs
changements dans l’état du publicateur.

Quand l’utiliser
Quand un objet veut publier des informations et que plusieurs objets nécessitent la réception de
cette information.

Bénéfices
Permet un couplage lâche entre publicateur et souscripteur, parce que le publicateur n’a pas
besoin de connaitre qui ou combien de souscripteurs il y a.

Conséquences/retombées
Dans un scénario complexe, il peut y avoir des problèmes pour déterminer quand est ce que la
mise à jour du publicateur est pertinente pour tous les souscripteurs ou certains d’entre eux.
Envoyer un message de mise à jour à tous les souscripteurs peut engendrer l’envoi d’un surplus
d’informations inutiles.
State
Définition
Le pattern State permet à un objet de modifier son comportement lorsque son état interne
change. En utilisant l'héritage et en laissant les classe filles représenter des états différents et
des fonctionnalités, nous pouvons changer en cours d'exécution. C’est un moyen propre pour
un objet de modifier partiellement son type durant l’exécution.

Quand l’utiliser
 Quand on a besoin de définir une classe « contexte » pour présenter une interface
unique au monde extérieur, en définissant une classe State abstraite de base.
 Lorsque nous voulons représenter différents "états" d'une machine (à états) comme
classes dérivées de la classe de base de l'état

Bénéfices
 Un code plus propre lorsque pour chaque état on a une classe
 Utiliser une classe pour représenter un état et non une constante

Conséquences/retombées
 Génère un nombre assez important de petites instances d’objets, mais concretement
simplifie et clarifie le programme.
 Élimine la nécessité d'un ensemble de déclarations conditionnelles longues et
semblables dispersés dans tout le code.
Strategy
Définition
On utilise le pattern strategy lorsqu’on a besoin de définir une famille d’algorithmes, encapsuler
chacun d’eux, et les rendre interchangeables. Le pattern Strategy rend l’algorithme variable
indépendamment du client qui l’utilise.
Le pattern strategy est lié au pattern state, flyweight, decorator, et composite.

Quand l'utiliser

 Quand on a besoin de plusieurs algorithmes, interchangeables dynamiquement.


 Lorsqu’on veut configurer une classe avec une de plusieurs classes reliées à elle
 Lorsque l’algorithme utilise des données que le client ne doit pas connaitre

Bénéfices
 Réduit les boucles if multiples pour le client
 Cache la complexité algorithmique ou les données spécifiques aux algorithmes au client
 Donne une alternative solide à la notion de sous classe ou classe fille
 Peut être utilisé lorsqu’on ne veut pas montrer toutes les données au client

Conséquences/retombées
Les clients doivent avoir connaissance de la différence entre les algorithmes, avant de pouvoir
en choisir un, ils doivent avoir le nécessaire pour choisir le plus optimale.
Augmente le nombre d’objets/classes dans une application.

Vous aimerez peut-être aussi