REPUBLIQUE DU CAMEROUN REPUBLIC OF CAMEROON

Paix-Travail-Patrie Peace-Work-Fatherland
-*-*-*- -*-*-*-
UNIVERSITÉ DE YAOUNDE 1 UNIVERSITY OF YAOUNDÉ 1
-*-*-*- -*-*-*-
Faculté des Sciences Faculty of Science
Département d’informatique Département of Computer Science
B.P 812 Yaoundé P.O. Box 812 Yaoundé

EXPOSE ICT 318

Thème :

DESIGN PATTERN STRATEGY

Membres du groupe :

- DJOKO NIE Marc Kevin 17E2424

- KAMDEM DJOKO Jaurel 17T2078
- BENGONO ZANG Joseph Elvis 17T2093
- BINELI OLA Mathilda Maguy 17T2215

Encadreur :
M NKOUANDOU Aboubakar
Enseignant à l’université de Yaoundé 1
 DESIGN PATTERN STRATEGY

Table des matières

INTRODUCTION ................................................................................................................................. 2
I. PRESENTATION GENERALE DU DESIGN PATTERN STRATEGY ................................ 3
1. Mise en Œuvre : .............................................................................................................................. 3
II. APPLICABILITE ..................................................................................................................... 4
III. SOLUTION ................................................................................................................................ 5
IV. CONSEQUENCES .................................................................................................................... 6
1. Avantages du design pattern strategy : ........................................................................................ 6
2. Inconvénients du design pattern strategy .................................................................................... 6
V. Relations avec d'autres modèles : ................................................................................................ 7
CONCLUSION ...................................................................................................................................... 8

Page 1|8
 DESIGN PATTERN STRATEGY

INTRODUCTION

Un design pattern est une façon générique d’organiser ses modules pour répondre à une
problématique peu importe le langage. Il en existe 3 types à savoir :

- Les design patterns de création : ils définissent comment faire l instanciation et la

configuration des classes et des objets.

- Les design patterns de structure : ils définissent comment organiser les classes d’un
programme dans une structure pus large.
- Les design patterns de comportement : ils définissent comment organiser les objets
pour que ceux-ci collaborent et expliquent le fonctionnement des algorithmes
impliqués. C’est le cas du design pattern strategy qui fera l’objet de notre étude.

Page 2|8
 DESIGN PATTERN STRATEGY

I. PRESENTATION GENERALE DU DESIGN PATTERN

STRATEGY

Le design pattern strategy est un patron de conception de type comportemental qui cherche
principalement à séparer un objet de ses comportements (algorithmes) en encapsulant es
derniers dans des classes à part. Il permet de :
- Définir une famille d’algorithmes, encapsuler chacun d’eux et les rendre
interchangeables.
- Utiliser différents algorithmes identiques sur le plan conceptuel en fonction du contexte
- Permettre aux algorithmes d’évoluer indépendamment des clients qui les utilisent.

1. Mise en Œuvre :

1. Dans la classe de contexte, identifiez un algorithme sujet à des changements fréquents.

Il peut également s'agir d'un conditionnel massif qui sélectionne et exécute une variante
du même algorithme au moment de l'exécution.
2. Déclarez l'interface de stratégie commune à toutes les variantes de l'algorithme.
3. Un par un, extrayez tous les algorithmes dans leurs propres classes. Ils devraient tous
mettre en œuvre l'interface de stratégie.
4. Dans la classe de contexte, ajoutez un champ pour stocker une référence à un objet de
stratégie. Fournissez un setter pour remplacer les valeurs de ce champ. Le contexte doit
fonctionner avec l'objet de stratégie uniquement via l'interface de stratégie. Le contexte
peut définir une interface permettant à la stratégie d'accéder à ses données.
5. Les clients du contexte doivent l'associer à une stratégie appropriée qui correspond à la
façon dont ils s'attendent à ce que le contexte exécute son travail principal.

Page 3|8
 DESIGN PATTERN STRATEGY

II. APPLICABILITE
Utilisez le modèle de stratégie lorsque vous souhaitez utiliser différentes variantes d'un
algorithme au sein d'un objet et pouvoir passer d'un algorithme à un autre pendant
l'exécution.

Le modèle de stratégie vous permet de modifier indirectement le comportement de l'objet au

moment de l'exécution en l'associant à différents sous-objets qui peuvent effectuer des sous-
tâches spécifiques de différentes manières.

Utilisez la stratégie lorsque vous avez beaucoup de classes similaires qui ne diffèrent que
par la façon dont elles exécutent certains comportements.

Le modèle de stratégie vous permet d'extraire le comportement variable dans une hiérarchie
de classes distincte et de combiner les classes d'origine en une seule, réduisant ainsi le code en
double.

Utilisez le modèle pour isoler la logique métier d'une classe des détails d'implémentation
d'algorithmes qui peuvent ne pas être aussi importants dans le contexte de cette logique.

Le modèle de stratégie vous permet d'isoler le code, les données internes et les dépendances
de divers algorithmes du reste du code. Divers clients disposent d'une interface simple pour
exécuter les algorithmes et les basculer au moment de l'exécution.

Utilisez le modèle lorsque votre classe a un opérateur conditionnel massif qui bascule
entre les différentes variantes du même algorithme.

Le modèle de stratégie vous permet de supprimer un tel conditionnel en extrayant tous les
algorithmes dans des classes distinctes, qui implémentent toutes la même interface. L'objet
d'origine délègue l'exécution à l'un de ces objets, au lieu d'implémenter toutes les variantes de
l'algorithme.

Page 4|8
 DESIGN PATTERN STRATEGY

III. SOLUTION

La solution proposée par le design pattern strategy consiste à :

- Encapsuler les algorithmes dans une hiérarchie et lier la hiérarchie a l’objet appelant
par composition
- Séparer la sélection de l’algorithme de son implémentation
- Permettre une sélection dynamique basée sur le contexte

Structure :

Page 5|8
 DESIGN PATTERN STRATEGY

IV. CONSEQUENCES

L’implémentation d’un design pattern strategy dans une application présente des
conséquences aussi bien positives que négatives.

1. Avantages du design pattern strategy :

- Une meilleure lisibilité du code
- Evite de violer un principe SOLID (le single responsibility principle)
- Forte extensibilité, réutilisabilité, flexibilité (les méthodes encapsulées dans les objets
seront utilisées dans différents contextes sans avoir à être redéfinies)
- Facilite l’ajout, la suppression et la modification d’un comportement
- Définit plusieurs algorithmes interchangeables dynamiquement

- Vous pouvez permuter les algorithmes utilisés à l'intérieur d'un objet lors de
l'exécution.
- Vous pouvez isoler les détails d'implémentation d'un algorithme du code qui l'utilise.
- Vous pouvez remplacer l'héritage par la composition.
- Principe ouvert / fermé . Vous pouvez introduire de nouvelles stratégies sans avoir à
changer le contexte.

2. Inconvénients du design pattern strategy

 Si vous n'avez que quelques algorithmes et qu'ils changent rarement, il n'y a pas de
raison réelle de compliquer le programme avec de nouvelles classes et interfaces qui
accompagnent le modèle.

 Les clients doivent être conscients des différences entre les stratégies pour pouvoir en
choisir une appropriée.

 De nombreux langages de programmation modernes ont un support de type

fonctionnel qui vous permet d'implémenter différentes versions d'un algorithme à
l'intérieur d'un ensemble de fonctions anonymes. Ensuite, vous pouvez utiliser ces
fonctions exactement comme vous auriez utilisé les objets de stratégie, mais sans
gonfler votre code avec des classes et des interfaces supplémentaires.

Page 6|8
 DESIGN PATTERN STRATEGY

V. Relations avec d'autres modèles :

Bridge , State , Strategy (et dans une certaine mesure Adapter ) ont des structures très
similaires. En effet, tous ces motifs sont basés sur la composition, qui délègue le travail à
d'autres objets. Cependant, ils résolvent tous des problèmes différents. Un modèle n'est
pas seulement une recette pour structurer votre code d'une manière spécifique. Il peut
également communiquer aux autres développeurs le problème résolu par le modèle.

La commande et la stratégie peuvent se ressembler car vous pouvez utiliser les deux pour
paramétrer un objet avec une action. Cependant, ils ont des intentions très différentes.

Vous pouvez utiliser Command pour convertir n'importe quelle opération en objet. Les
paramètres de l'opération deviennent des champs de cet objet. La conversion vous permet
de différer l'exécution de l'opération, de la mettre en file d'attente, de stocker l'historique
des commandes, d'envoyer des commandes aux services distants, etc.

D'un autre côté, Strategy décrit généralement différentes façons de faire la même chose,
vous permettant d'échanger ces algorithmes dans une seule classe de contexte.

Decorator vous permet de changer la peau d'un objet, tandis que Strategy vous permet de
changer les tripes.

La méthode de modèle est basée sur l'héritage: elle vous permet de modifier des parties
d'un algorithme en étendant ces parties dans des sous-classes. La stratégie est basée sur la
composition: vous pouvez modifier certaines parties du comportement de l'objet en lui
fournissant différentes stratégies correspondant à ce comportement. La méthode Template
fonctionne au niveau de la classe, elle est donc statique. La stratégie fonctionne au niveau
de l'objet, vous permettant de changer de comportement lors de l'exécution.

L'État peut être considéré comme une extension de la stratégie . Les deux modèles sont
basés sur la composition: ils modifient le comportement du contexte en déléguant du
travail à des objets auxiliaires. La stratégie rend ces objets complètement indépendants et
inconscients les uns des autres. Cependant, State ne restreint pas les dépendances entre les
états concrets, les laissant modifier à volonté l'état du contexte.

Page 7|8
 DESIGN PATTERN STRATEGY

CONCLUSION

En somme, un design pattern strategy est un patron de conception comportemental qui permet
de définir une famille d'algorithmes, de placer chacun d'eux dans une classe distincte et de
rendre leurs objets interchangeables.

Page 8|8