DB
Téléchargé parDorra BARTAGUIZ
PDF, PPTX1,026 vues

Design patterns

Ce document explique les design patterns en C#, en définissant des modèles tels que Composite, Singleton, Façade, Strategy, et Template Method, avec des exemples concrets et des situations d'utilisation. Il couvre également les principes SOLID et l'importance de la factorisation pour une meilleure organisation du code. Enfin, les cas d'utilisation illustrent comment ces patterns peuvent améliorer la structure et la maintenance des projets logiciels.

Intégrer la présentation

Télécharger en tant que PDF, PPTX
1 / 147
2 / 147
3 / 147
4 / 147
5 / 147
6 / 147
7 / 147
8 / 147
9 / 147
10 / 147
11 / 147
12 / 147
13 / 147
14 / 147
15 / 147
16 / 147
17 / 147
18 / 147
19 / 147
20 / 147
21 / 147
22 / 147
23 / 147
24 / 147
25 / 147
26 / 147
27 / 147
28 / 147
29 / 147
30 / 147
31 / 147
32 / 147
33 / 147
34 / 147
35 / 147
36 / 147
37 / 147
38 / 147
39 / 147
40 / 147
41 / 147
42 / 147
43 / 147
44 / 147
45 / 147
46 / 147
47 / 147
48 / 147
49 / 147
50 / 147
51 / 147
52 / 147
53 / 147
54 / 147
55 / 147
56 / 147
57 / 147
58 / 147
59 / 147
60 / 147
61 / 147
62 / 147
63 / 147
64 / 147
65 / 147
66 / 147
67 / 147
68 / 147
69 / 147
70 / 147
71 / 147
72 / 147
73 / 147
74 / 147
75 / 147
76 / 147
77 / 147
78 / 147
79 / 147
80 / 147
81 / 147
82 / 147
83 / 147
84 / 147
85 / 147
86 / 147
87 / 147
88 / 147
89 / 147
90 / 147
91 / 147
92 / 147
93 / 147
94 / 147
95 / 147
96 / 147
97 / 147
98 / 147
99 / 147
100 / 147
101 / 147
102 / 147
103 / 147
104 / 147
105 / 147
106 / 147
107 / 147
108 / 147
109 / 147
110 / 147
111 / 147
112 / 147
113 / 147
114 / 147
115 / 147
116 / 147
117 / 147
118 / 147
119 / 147
120 / 147
121 / 147
122 / 147
123 / 147
124 / 147
125 / 147
126 / 147
127 / 147
128 / 147
129 / 147
130 / 147
131 / 147
132 / 147
133 / 147
134 / 147
135 / 147
136 / 147
137 / 147
138 / 147
139 / 147
140 / 147
141 / 147
142 / 147
143 / 147
144 / 147
145 / 147
146 / 147
147 / 147
Design Patterns En C#
Qui suis-je ? • Dorra BARTAGUIZ • Software craftswoman • Tech lead • Coach technique • Peu importe le langage • .Net, java, php, python, js dorra.bartaguiz@outlook.com
Programme Du code C# à faire/factoriser Contexte Problématique Extraire le design pattern
Des questions ? C’est parti 
Design pattern - Définition • Modèle de conception • Décrit les cas d’utilisation • Sert d’abstraction au modèle d’implémentation • Intension, motivation, solution • Une solution à un problème générique
Premier exemple • Projet à récupérer de GitHub • https://github.com/iAmDorra/DesignPatterns Folder + Name : String File + Name : String contains contains
Solution & Projet • Définir le projet (ou les) de démarrage • Références d’un projet • Un autre projet • Une librairie du Framework • Un composant COM • … Project 1 Project 2 References Solution Project 3 References Project 4 2 1 1' 3 References x Build order
Premier exemple • Contexte : • Un dossier peut contenir des fichiers et des dossiers Folder + Name : String File + Name : String contains contains
Premier exemple • Inconvénients : • Pour connaitre le contenu de Folder, il faut parcourir les deux listes Folder + Name : String File + Name : String contains contains
Premier exemple • Pour connaitre le contenu de Folder, il faut parcourir une seule collection Folder + Name : String File + Name : String <<Interface>> IElement + Name : String
Premier exemple • Caractéristiques • Eviter la duplication • Extensible => Pattern « Composite » Folder + Name : String File + Name : String contains contains Folder + Name : String File + Name : String <<Interface>> IElement + Name : String
Exercice • Ajouter un lien (Link) • Un lien peut référencer un fichier ou un dossier (pas les deux) • Un dossier peut contenir des liens Folder + Name : String File + Name : String <<Interface>> IElement + Name : String
Petits rappels avant 
SOLID • S RP : Single Responsibility Principle • O CP : Open Close Principle • L SP : Liskov Substitution Principle • I SP : Interface Separation Principle • D IP : Dependency Inversion Principle
Classification des patterns • GoF (Gang of four) classification • Creational patterns (de construction) • Behavior patterns (de comportement) • Structural patterns (de structuration)
Revenons à nos moutons 
Composite • Permettre à un client d’interagir avec un objet sans connaitre la profondeur de sa composition • Limiter les dépendances entre les classes concrètes • Eviter la duplication • Extensible Folder + Name : String File + Name : String <<Interface>> IElement + Name : String
Composite – use cases • Il est nécessaire de représenter des hiérarchies de composition • Les clients de la composition doivent ignorer s’ils communiquent avec des objets composés ou non Folder + Name : String File + Name : String <<Interface>> IElement + Name : String
Use Case 
Le système solaire • Il est composé de : • Le soleil • Des planètes • Autres étoiles et objets célestes
Le système solaire Sun - instance : Sun + GetInstance() : Sun private static Sun instance = new Sun(); private Sun() { } public static Sun GetInstance() { return instance; }
Singleton • Assurer qu’une classe ne possède qu’une seule instance et de fournir une méthode de classe unique retournant cette instance Singleton - instance : Singleton + GetInstance() : Singleton private static Singleton instance = new Singleton(); private Singleton() { } public static Singleton GetInstance() { return instance; }
Singleton – use cases • Il ne doit y avoir qu’une seule instance • Cette instance n’est accessible qu’à travers une méthode de classe • Eviter une variable globale Singleton - instance : Singleton + GetInstance() : Singleton private static Singleton instance = new Singleton(); private Singleton() { } public static Singleton GetInstance() { return instance; }
Singleton – use cases On peut avoir une version lazy du singleton Singleton - instance : Singleton + GetInstance() : Singleton private static Singleton instance; public static Singleton GetInstance() { if(instance == null) instance = new Singleton(); return instance }
Singleton – attention • Si on est en multithreading, ajout un lock pour l’instance • Eviter les méthodes qui set l’instance à null Singleton - instance : Singleton + GetInstance() : Singleton + Reset() public static Singleton GetInstance() { if(instance == null) instance = new Singleton(); return instance } public void Reset() { instance = null; } var first = Singleton.GetInstance(); // first pointe donc sur un objet en mémoire first .Reset(); var second = Singleton.GetInstance(); // => on a donc deux instances en mémoire
Use Case 
Appel au service client • Un client achète un article sur un site et paye par carte bancaire • Il veut changer l’adresse de livraison et rajouter une option dans l’article • Le changement d’adresse est au service de facturation • L’ajout de l’option est au service de commande • Il appelle le service client qui se charge de tout
Appel au service client CustomerService + UpdateAdress(Client client, Adress newAdress) + AddOption(Order order, Option option) Billing + AddOption(Order order, Option option) + Edit(Order order) Ordering +UpdateAdress(Client client, Adress newAdress) Uses public void UpdateAdress(Client client, Adress newAdress) { ordering.UpdateAdress(client, newAdress); } public void AddOption(Order order, Option option) { billing.AddOption(order, option); }
Façade • Créer une interface unifiée au sous-système • Un objet composé de plusieurs services Facade + RunMethod1(parameter1, parameter2) + RunMethod3() + RunMethod4(parameter3) Service3 + RunMethod4(parameter3) + RunMethod5(parameter) Service2 + RunMethod3() Service1 + RunMethod1(parameter1, parameter2) + RunMethod2()
Façade – use cases • Dissimuler/faciliter au client la complexité des activités internes • Besoin de contrôler les modes d’accès aux composants • Un point d’entrée au sous-système Facade + RunMethod1(parameter1, parameter2) + RunMethod3() + RunMethod4(parameter3) Service3 + RunMethod4(parameter3) + RunMethod5(parameter) Service2 + RunMethod3() Service1 + RunMethod1(parameter1, parameter2) + RunMethod2()
Façade – attention • Fort couplage • Degré de dépendance d’un module vis-à- vis d’un autre • Faible cohésion • Degré de cohérence des responsabilités d’un module Facade + RunMethod1(parameter1, parameter2) + RunMethod3() + RunMethod4(parameter3) Service3 + RunMethod4(parameter3) + RunMethod5(parameter) Service2 + RunMethod3() Service1 + RunMethod1(parameter1, parameter2) + RunMethod2()
Use Case 
Compresser des données • On a besoin de compresser des données • Codage par répétition • AAA0000111FF => 3A40312F • Codage entropique (de Huffman ou arithmétique) • Pattern => 000 001 11 11 010 011 10
Compresser des données Compressor + string Compress(string data) <<Interface>> ICompressor + string Compress(string data) public string Compress(string data) { switch (this.compressionType) { case CompressionType.Repetition: return CompressWithRepetitionAlgo(data); case CompressionType.Entropic: return CompressWithEntropicAlgo(data); case CompressionType.ByDictionary: return CompressByDictionaryAlgo(data); default: return data; } }
Compresser des données RepetitionCompressor + string Compress(string data) <<Interface>> ICompressor + string Compress(string data) EntropicCompressor + string Compress(string data) Context - compressor : ICompressor + string Compress(string data) ByDictionaryCompressor + string Compress(string data) public string Compress(string data) { compressor.Compress(data); }
Strategy • Adapter le comportement d’un objet en fonction d’un besoin sans changer les interactions de cet objet avec les clients • Représenter les comportements variables sous forme de classes • Les comportements/algorithmes sont interchangeables ConcreteStrategyA + Calculate() <<Interface>> Strategy + Calculate() ConcreteStrategyB + Calculate() Context + Execute() void Execute() { strategy.Calculate(); }
Strategy – use cases • Besoin d’implémenter plusieurs comportements pour un traitement • Protéger les variations en séparant les parties variantes et invariantes ConcreteStrategyA + Calculate() <<Interface>> Strategy + Calculate() ConcreteStrategyB + Calculate() Context + Execute() void Execute() { strategy.Calculate(); }
Strategy – attention • Quand les contextes sont responsables du choix de la stratégie ConcreteStrategyA + Calculate() <<Interface>> Strategy + Calculate() ConcreteStrategyB + Calculate() Context + Execute() void Execute() { strategy.Calculate(); }
Use Case 
Chez le concessionnaire • Le concessionnaire gère les commandes issues de client de la France et du Luxembourg. • La différence entre les commandes concerne le calcul de la TVA • France : TVA = 19,6% • Luxembourg : TVA = 12% pour les prestations et 15% pour le matériel
Chez le concessionnaire • Montant = HT + TVA <<Interface>> IOrder +CalculateAmount() FrenchOrder -preTaxAmount +CalculateAmount() LuxembourgishOrder -preTaxServiceAmount -preTaxMaterialAmount +CalculateAmount() public double CalculateAmount() { var vatAmount = preTaxAmount * 0.196; var amount = preTaxAmount + vatAmount; return amount; } public double CalculateAmount() { var vatAmount = preTaxServiceAmount * 0.12 + preTaxMaterialAmount * 0.15; var preTaxAmount = preTaxServiceAmount + preTaxMaterialAmount; var amount = preTaxAmount + vatAmount; return amount; }
Chez le concessionnaire • Montant = HT + TVA • Extraire les méthodes • Mieux voir les factorisations futures <<Interface>> IOrder +CalculateAmount() FrenchOrder -preTaxAmount +CalculateAmount() LuxembourgishOrder -preTaxServiceAmount -preTaxMaterialAmount +CalculateAmount() public double CalculateAmount() { var amount = CalculatePreTaxAmount()+ CalculateVat(); return amount; } private double CalculateVat() { return preTaxAmount * 0.196; } private double CalculatePreTaxAmount() { return preTaxAmount; } public double CalculateAmount() { var amount = CalculatePreTaxAmount()+ CalculateVat(); return amount; } private double CalculateVat() { return preTaxServiceAmount * 0.12 + preTaxMaterialAmount * 0.15; } private double CalculatePreTaxAmount() { return preTaxServiceAmount + preTaxMaterialAmount; }
Chez le concessionnaire • Montant = HT + TVA • Factoriser le comportement dans la classe de base • Implémenter les spécificités dans les classes filles <<Interface>> IOrder +CalculateAmount() FrenchOrder -preTaxAmount #CalculateVat() #CalculatePreTaxAmount() LuxembourgishOrder -preTaxServiceAmount -preTaxMaterialAmount #CalculateVat() #CalculatePreTaxAmount() <<Abstract>> BaseOrder +CalculateAmount() #CalculateVat() #CalculatePreTaxAmount() protected override double CalculateVat() { return preTaxAmount * 0.196; } protected override double CalculatePreTaxAmount() { return preTaxAmount; } protected override double CalculateVat() { return preTaxServiceAmount * 0.12 + preTaxMaterialAmount * 0.15; } protected override double CalculatePreTaxAmount() { return preTaxServiceAmount + preTaxMaterialAmount; } public double CalculateAmount() { return CalculateVat() + CalculatePreTaxAmount(); } protected abstract double CalculateVat(); protected abstract double CalculatePreTaxAmount();
Template method • Reporter aux filles certaines étapes d’un traitement • Les étapes sont implémentées dans les classes filles ConcreteClass #Operation1() #Operation2() <<Abstract>> BaseClass +TemplateMethod() #Operation1() #Operation2() public void TemplateMethod() { ... Operation1(); ... Operation2(); ... } protected abstract void Operation1(); protected abstract void Operation2(); protected override void Operation1() { ... } protected override void Operation2() { ... }
Template method – use cases • Deux classes ou plusieurs partagent du code identique • Les parties spécifiques déplacées dans les filles • Un algorithme avec une partie invariable et des parties spécifiques à différents objets ConcreteClass #Operation1() #Operation2() <<Abstract>> BaseClass +TemplateMethod() #Operation1() #Operation2() public void TemplateMethod() { ... Operation1(); ... Operation2(); ... } protected abstract void Operation1(); protected abstract void Operation2(); protected override void Operation1() { ... } protected override void Operation2() { ... }
Use Case 
L’usine à chaussures • L’usine crée • Des chaussures de ville, des sandales • En cuir ou synthétiques ShoeCreator + CreateLeatherShoe() + CreateLeatherSandal() + CreateSyntheticShoe() + CreateSyntheticSandal() IShoe -type Client Sandal -type StreetShoe -type public StreetShoe CreateLeatherShoe() { return new StreetShoe(ShoeType.Leather); } public Sandal CreateSyntheticSandal() { return new Sandal(ShoeType.Synthetic); }
L’usine à chaussures ShoeCreator + CreateShoe() + CreateSandal() IShoe Client Sandal StreetShoe LeatherFabric + CreateShoe() + CreateSandal() SyntheticFabric + CreateShoe() + CreateSandal() LeatherSandal SyntheticSandal LeatherStreetShoe SyntheticStreetShoe public StreetShoe CreateShoe() { return new LeatherStreetShoe(); } public Sandal CreateSandal() { return new LeatherSandal(); } public StreetShoe CreateShoe() { return new SyntheticStreetShoe(); } public Sandal CreateSandal() { return new SyntheticSandal(); }
Abstract factory • Créer des objets regroupés en familles sans devoir connaître les classes concrètes destinées à la création de ces objets • Configuration flexible • Les implémentations doivent changer en fonction de certains paramètres AbstractFabric + CreateProductA() + CreateProductB() Client ProductA ProductB ConcreteFabric1 + CreateProductA() + CreateProductB() ConcreteFabric2 + CreateProductA() + CreateProductB() ProductA1 ProductA2 ProductB1 ProductB2
Abstract factory – use cases • Un système utilisant des produits a besoin d’être indépendant de la façon dont ces produits sont créés et regroupés • Un système est paramétré par plusieurs familles de produits qui peuvent évoluer AbstractFabric + CreateProductA() + CreateProductB() Client ProductA ProductB ConcreteFabric1 + CreateProductA() + CreateProductB() ConcreteFabric2 + CreateProductA() + CreateProductB() ProductA1 ProductA2 ProductB1 ProductB2
Abstract factory - attention • Si une règle de gestion exige de ne pas pouvoir créer des sandales en synthétique par exemple, ce pattern ne correspond pas car on va implémenter la méthode CreateSandal pour le synthétique • Risque de créer des objets incompatibles entre eux AbstractFabric + CreateProductA() + CreateProductB() Client ProductA ProductB ConcreteFabric1 + CreateProductA() + CreateProductB() ConcreteFabric2 + CreateProductA() + CreateProductB() ProductA1 ProductA2 ProductB1 ProductB2
Use Case 
Faire du shopping • Un client commande des articles sur internet • Statuts de la commande : • En cours : le client est en train de choisir les articles • Validée : le client valide et paye la commande • Livrée : le client reçoit les articles
Faire du shopping • Inconvénients • Il faut gérer tous les statuts dans les méthodes • Les transitions des statuts sont gérées par la commande Order - state - items + AddItem() + RemoveItem() + NextState() public void AddItem(Item item) { if(state == InProgress) { items.Add(item); } else { throw new System.NotSupportedException(); } } public void RemoveItem(Item item) { if(state == InProgress || state == Validated) { items.Remove(item); } else { throw new System.NotSupportedException(); } }
Faire du shopping • Inconvénients • Il faut gérer tous les statuts dans les méthodes • Les transitions des statuts sont gérées par la commande • Nouvel objet à chaque modif de statut Order -state -items +AddItem() +RemoveItem() +NextState() InprogressOrder +AddItem() +RemoveItem() ValidatedOrder +AddItem() +RemoveItem() DeliveredOrder +AddItem() +RemoveItem() public void AddItem(Item item) { throw new NotSupportedException(); } public void RemoveItem(Item item) { throw new NotSupportedException(); } public void AddItem(Item item) { throw new NotSupportedException(); } public void RemoveItem(Item item) { items.Remove(item); } public void AddItem(Item item) { items.Add(item); } public void RemoveItem(Item item) { items.Remove(item); }
Faire du shopping • Inconvénients • Il faut gérer tous les statuts dans les méthodes • Les transitions des statuts sont gérées par la commande • Nouvel objet à chaque modif de statut OrderStatus +AddItem() +RemoveItem() InprogressStatus +AddItem() +RemoveItem() ValidatedStatus +AddItem() +RemoveItem() DeliveredStatus +AddItem() +RemoveItem() Order -state -items +AddItem() +RemoveItem() +NextState() public void AddItem(Item item) { throw new NotSupportedException(); } public void RemoveItem(Item item) { throw new NotSupportedException(); } public void AddItem(Item item) { throw new NotSupportedException(); } public void RemoveItem(Item item) { items.Remove(item); } public void AddItem(Item item) { items.Add(item); } public void RemoveItem(Item item) { items.Remove(item); } public void AddItem(Item item) { state.AddItem(item); } public void RemoveItem(Item item) { state.RemoveItem(item); }
State • Permet à un objet (Context) d’adapter son comportement en fonction de son état interne Context +Request() State +Handle() ConcreteStateA +Handle() ConcreteStateB +Handle() Request() { state.Handle(); }
State – use cases • Le comportement d’un objet dépend de son état • L’implémentation par des instructions conditionnelles est trop complexe Context +Request() State +Handle() ConcreteStateA +Handle() ConcreteStateB +Handle() Request() { state.Handle(); }
State – attention • Ne pas implémenter si deux états (simples) Context +Request() State +Handle() ConcreteStateA +Handle() ConcreteStateB +Handle() Request() { state.Handle(); }
Use Case 
Comparateur d'hôtels • J’ai créé un service de comparaison des hôtels du coin • Je veux cherche des clients potentiels pour mon service Comparator + GetAvailableRooms(Date) : List<RoomPrice> <<Interface>> IComparator + GetAvailableRooms(Date) : List<RoomPrice>
Comparator + GetAvailableRooms(Date) : List<RoomPrice> Client <<Interface>> IComparator + GetRoomAvailailities(Date) : List<RoomAvailability> <<Interface>> IComparator + GetAvailableRooms(Date) : List<RoomPrice> Comparateur d'hôtels • Le client impose un contrat de service qui lui correspond ?
Comparateur d'hôtels • Le client impose un contrat de service qui lui correspond Comparator + GetAvailableRooms(Date) : List<RoomPrice> Client <<Interface>> IComparator + GetRoomAvailailities(Date) : List<RoomAvailability> <<Interface>> IComparator + GetAvailableRooms(Date) : List<RoomPrice> ComparatorAdaptor + GetRoomAvailailities(Date) : List<RoomAvailability>
Adapter • Convertir une class existante en une interface attendue par les clients également existants afin qu’ils puissant travailler ensemble Adaptee + SpecificRequest() Client <<Interface>> ITarget + Request() Adapter + Request() adaptee.SpecificRequest()
Adapter – use cases • Intégrer dans un système un objet dont l’interface ne correspond pas à l’interface requise au sein de ce système • Fournir des interfaces multiples à un objet lors de sa conception Adaptee + SpecificRequest() Client <<Interface>> ITarget + Request() Adapter + Request() adaptee.SpecificRequest()
Adapter – attention • Il y aura autant d’adaptateurs que de fournisseur Adaptee + SpecificRequest() Client <<Interface>> ITarget + Request() Adapter + Request() adaptee.SpecificRequest()
Use Case 
Compter le nombre de LIKE • Dans mon application, j’ai un service pour liker mon produit • Créer un service de comptage LikeCounter + CountLikes() ProductAnalysis + LikeProduct()
Compter le nombre de LIKE LikeCounter + Update(int) <<Interface>> ILikeCounter + Update(int) ProductAnalysis - List<ILikeCounter> counters + Add(ILikeCounter) + LikeProduct() public void Add(ILikeCounter counter) { counters.Add(counter); } public void LikeProduct() { likesNumber ++; foreach(var counter in this.counters) { counter.Update(likesNumber); } } public LikeCounter(ProductAnalysis product) { product.Add(this); } public void Update(int number) { Console.WriteLine(number); }
Observer • Permet aux observateurs de mettre à jour leur état quand le sujet est modifié <<abstract>> Subject + Add(Observer) + Remove(Observer) + Notify() ConcretSubject - subjectState + GetState() <<abstract>> Observer + Update() ConcreteObserver - observerState + Update() subject observer return subjectState; public void Add(Observer observer) { this.observers.Add(observer); } public void Notify() { foreach(var obs in observers) { obs.Update(); } } public void Update() { observerState = subject.GetState(); }
Observer – use cases • La modification d’un objet engendre des modifications dans d’autres objets qui sont déterminés dynamiquement • Un objet veut prévenir d’autres objets sans devoir connaitre leur type • pas de couplage <<abstract>> Subject + Add(Observer) + Remove(Observer) + Notify() ConcretSubject - subjectState + GetState() <<abstract>> Observer + Update() ConcreteObserver - observerState + Update() subject observer return subjectState; public void Add(Observer observer) { this.observers.Add(observer); } public void Notify() { foreach(var obs in observers) { obs.Update(); } } public void Update() { observerState = subject.GetState(); }
Observer – Attention • Plusieurs implémentations • Garder le statut dans le sujet et l’appeler dans la méthode Update de l’observer • Ne pas exposer le statut du sujet et envoyer Event (contient les infos de notification) <<abstract>> Subject + Add(Observer) + Remove(Observer) + Notify(Event) <<abstract>> Observer + Update(Event) ConcreteObserver - observerState + Update(Event) observer public void Add(Observer observer) { this.observers.Add(observer); } public void Notify(Event e) { foreach(var obs in observers) { obs.Update(e); } } public void Update(Event e) { observerState = e; }
Use Case 
Composer son PC • Choisir les options • Taille écran : 11’, 16’ … • Processeur : i5, i7 … • Mémoire RAM : 12 Go, 16 Go … • Taille du disque dur : 1To, SSD … • Carte vidéo : NVIDIA, AMD … • Casque : USB, Bluetooth … • Souris : filaire, sans fil… • Sac : à dos, sacoche … • Clavier : Azerty, Querty • Chaque option a un prix • Le prix du PC = prix de base (300€) + somme des options
Use Case 
Chez le dentiste • L’assistante accueille les patients par ordre d’arrivée • Le dentiste ne sait pas s’il y a un patient qui attend, ni qui il est • Il demande de faire entrer le suivant • Il ne s’intéresse pas à la façon dont la salle d’attente est gérée. Dentist + EnterNext() Patient - name works with Secretary - patients : Collection<Patient> + HasNext() : bool + Next() : Patient
Chez le dentiste • Introduire la notion de collection pour dissocier la collection en tant que tel et la manière de la parcourir • Si on change la règle d’itération par arrivée en itération par priorité Dentist + EnterNext() Patient - name works with Secretary + HasNext() : bool + Next() : Patient Patients +
Chez le dentiste Dentist + EnterNext() Secretary + HasNext() : bool + Next() : Patient Patients + GetIterator() : IIterator <<Interface>> IIterable + GetIterator() : IIterator <<Interface>> IIterator + HasNext() : bool + Next() : IElement implements <<Interface>> IElement Name Patient Name instanciate IIterator GetIterator() { return new Secretary(); } void EnterNext() { IIterator iterator = this.patients.GetIterator(); if(iterator.HasNext()) { this.Receive(iterator.Next()); } }
Iterator • Fournir un accès séquentiel à une collection à des clients sans que ceux-ci doivent se préoccuper de l’implémentation de cette collection • Parcours séquentiel / variable • Enumération Client + DoSomething() ConcreteIterator<Element> + HasNext() : bool + Next() : Element ConcreteIterable + GetIterator() : IIterator<IElement> <<Interface>> IIterable + GetIterator() : IIterator<IElement> <<Interface>> IIterator<IElement> + HasNext() : bool + Next() : IElement implements <<Interface>> IElement Element instanciate void DoSomething() { IIterator<IElement> iterator = this.iterable.GetIterator(); if(iterator.HasNext()) { this.Receive(iterator.Next()); } }
Iterator – use cases • Parcours du contenu d’une collection sans accéder à sa représentation interne • Gérer plusieurs parcours simultanément Client + DoSomething() ConcreteIterator<Element> + HasNext() : bool + Next() : Element ConcreteIterable + GetIterator() : IIterator<IElement> <<Interface>> IIterable + GetIterator() : IIterator<IElement> <<Interface>> IIterator<IElement> + HasNext() : bool + Next() : IElement implements <<Interface>> IElement Element instanciate void DoSomething() { IIterator<IElement> iterator = this.iterable.GetIterator(); if(iterator.HasNext()) { this.Receive(iterator.Next()); } }
Iterator – Attention • L’ordre n’est pas maitrisé par le client mais plutôt par l’itérateur Client + DoSomething() ConcreteIterator<Element> + HasNext() : bool + Next() : Element ConcreteIterable + GetIterator() : IIterator<IElement> <<Interface>> IIterable + GetIterator() : IIterator<IElement> <<Interface>> IIterator<IElement> + HasNext() : bool + Next() : IElement implements <<Interface>> IElement Element instanciate void DoSomething() { IIterator<IElement> iterator = this.iterable.GetIterator(); if(iterator.HasNext()) { this.Receive(iterator.Next()); } }
Use Case 
Catalogue de films • Au lieu de charger tout le film en mémoire, on affiche une image • Un clic sur la photo permet de jouer le film • But : réduire la quantité de mémoire utilisée
Catalogue de films • Au lieu de charger tout le film en mémoire, on affiche une image • Un clic sur la photo permet de jouer le film • But : réduire la quantité de mémoire utilisée Animation + Show() + Clic() Film + Show() + Clic() + Run() AnimationSubstitute # photo + Show() + Clic() 0..1 #film public void Show() { if(film == null) photo.Show(); else film.Show(); } public void Clic() { if(film == null) { film = new Film(); } film.Run(); }
Proxy • Concevoir un objet qui se substitue à un autre et qui en contrôle l’accès <<Interface>> ISubject + DoSomething() RealSubject + DoSomething() Proxy - wrapee + DoSomething() Client public void DoSomething() { // Optionnal functionnality wrapee.DoSomething(); // Optionnal functionnality }
Proxy – use cases • Proxy virtuel : créer un objet de taille importante au moment approprié • Proxy remote : accéder à un objet s’exécutant sur un autre environnement • Proxy de protection : sécuriser l’accès à un objet (authentification) <<Interface>> ISubject + DoSomething() RealSubject + DoSomething() Proxy - wrapee + DoSomething() Client public void DoSomething() { // Optionnal functionnality wrapee.DoSomething(); // Optionnal functionnality }
Use Case 
Chez le grossiste de fournitures bureau • Tous les mois, l’école passe la même commande de fournitures (stylo, feutres, papiers …) • Afin de faciliter la saisie pour ses clients, le grossiste a décidé de fournir une fonctionnalité de duplication de commande passée
Chez le grossiste de fournitures bureau • Fonctionnalité de duplication de commande <<Interface>> ICloneableOrder + Clone() Order + Clone() Client + CreateOrderFromAnother() order public void CreateOrderFromAnother() { ... var newOrder = order.Clone(); ... } public ICloneableOrder Clone() { return this.MemberwiseClone(); }
Prototype • Créer de nouveaux objets par duplication d’objets existants qui disposent de la capacité de clonage <<Interface>> IPrototype + Clone() ContretePrototype1 + Clone() ContretePrototype2 + Clone() Client + Operation() prototype public void Operation() { ... var clone = prototype.Clone(); ... } public IPrototype Clone() { return this.MemberwiseClone(); }
Prototype – uses cases • Créer des instances sans connaitre la hiérarchie des classes <<Interface>> IPrototype + Clone() ContretePrototype1 + Clone() ContretePrototype2 + Clone() Client + Operation() prototype public void Operation() { ... var clone = prototype.Clone(); ... } public IPrototype Clone() { return this.MemberwiseClone(); }
Prototype – attention • Maitriser la duplication pour ne pas dégrader la performance
Use Case 
Faire du shopping • Un client commande des articles sur internet • Statuts de la commande : • En cours : le client est en train de choisir les articles • Validée : le client valide et paye la commande • Livrée : le client reçoit les articles
Memento • Sauvegarder et restaurer l’état d’un objet sans en violer l’encapsulation Originator - state + SetMemento(Memento); + CreateMemento(); Memento - state + GetState() CareTaker public void SetMemento(Memento memento) { state = memento.GetState(); } public Memento CreateMemento() { return new Memento(state); }
Memento – use cases • Quand l’état interne d’un objet (totalement ou partiellement) doit être mémorisé afin de pouvoir être restauré ultérieurement sans que l’encapsulation de cet objet ne doive être brisée Originator - state + SetMemento(Memento); + CreateMemento(); Memento - state + GetState() CareTaker public void SetMemento(Memento memento) { state = memento.GetState(); } public Memento CreateMemento() { return new Memento(state); }
Use Case 
L’usine à chaussures • Ajouter un nouveau type : botte de pluie • Complexité combinatoire IShoe Sandal StreetShoe LeatherSandal SyntheticSandal LeatherStreetShoe SyntheticStreetShoe RainBoot LeatherRainBoot SyntheticRainBoot
L’usine à chaussures • Eviter la complexité combinatoire <<Interface>> IShoe <<Interface>> IMaterial Sandal Shoe RainBoot Leather Synthetic
Bridge • Séparer l’aspect d’implémentation d’un objet de son aspect de représentation et d’interface <<Interface>> IAbstraction + DoOperation() Client <<Interface>> IImplementor + DoOperationImplem() RefinedAbstraction ConcreteImplementorA + DoOperationImplem() ConcreteImplementorB + DoOperationImplem() DoOperation() { implementor.DoOperationImplem(); }
Bridge – use cases • Eviter une liaison forte entre la représentation des objets et leur implémentation • Changer la représentation des objets sans impacter les interactions entre les objets et les clients • Garder la capacité d’extension par la création de nouvelles sous- classes • Eviter d’obtenir des hiérarchies de classes extrêmement complexes <<Interface>> IAbstraction + DoOperation() Client <<Interface>> IImplementor + DoOperationImplem() RefinedAbstraction ConcreteImplementorA + DoOperationImplem() ConcreteImplementorB + DoOperationImplem() DoOperation() { implementor.DoOperationImplem(); }
Use Case 
Elements • Changement de Write(), 3 fichiers touchés Folder + Name : String File + Name : String <<Interface>> IElement + Name : String <<Interface>> IReferenceableElement Link + Name : String References + Write() + Write() + Write() + Write()
Elements Folder + Name : String File + Name : String <<Interface>> IElement + Name : String <<Interface>> IReferenceableElement Link + Name : String References + Accept(IWriter writer) + Accept(IWriter writer) + Accept(IWriter writer) + Accept(IWriter writer) Writer + Write(IElement element) + Write(Link link) + Writer(File file) + Write(Folder folder) <<Interface>> IWriter + Write(IElement element) + Write(Link link) + Writer(File file) + Write(Folder folder) public Write(IElement element) { element.Accept(this); } public Write(Link link) { Console.WriteLine(link.Name); } ... public Accept(IWriter writer) { writer.Write(this); }
Visitor • Construire une opération à réaliser sur les éléments d’un ensemble d’objets • De nouvelles opérations peuvent ainsi être ajoutées sans modifier les classes de ces objets <<Interface>> IElement + AcceptVisitor(IVisitor visitor) ConcreteElement1 + AcceptVisitor(IVisitor visitor) ConcreteElement2 + AcceptVisitor(IVisitor visitor) <<Interface>> IVisitor + Visit(ConcreteElement1 element) + Visit(ConcreteElement2 element) ConcreteVisitor1 + Visit(ConcreteElement1 element) + Visit(ConcreteElement2 element) ConcreteVisitor2 + Visit(ConcreteElement1 element) + Visit(ConcreteElement2 element) public AcceptVisitor(IVisitor visitor) { visitor.Visit(this); }
Visitor – use case • De nouvelles fonctionnalités doivent être ajoutées à un ensemble de classes sans que ces ajouts viennent alourdir ces classes • Un ensemble de classes possèdent une structure fixe et il est nécessaire de leur adjoindre des fonctionnalités sans modifier leur interface <<Interface>> IElement + AcceptVisitor(IVisitor visitor) ConcreteElement1 + AcceptVisitor(IVisitor visitor) ConcreteElement2 + AcceptVisitor(IVisitor visitor) <<Interface>> IVisitor + Visit(ConcreteElement1 element) + Visit(ConcreteElement2 element) ConcreteVisitor1 + Visit(ConcreteElement1 element) + Visit(ConcreteElement2 element) ConcreteVisitor2 + Visit(ConcreteElement1 element) + Visit(ConcreteElement2 element) public AcceptVisitor(IVisitor visitor) { visitor.Visit(this); }
Visitor – attention • Complexité • Cycle de dépendance • Il faut avoir des getters dans les classes utilisées <<Interface>> IElement + AcceptVisitor(IVisitor visitor) ConcreteElement1 + AcceptVisitor(IVisitor visitor) ConcreteElement2 + AcceptVisitor(IVisitor visitor) <<Interface>> IVisitor + Visit(ConcreteElement1 element) + Visit(ConcreteElement2 element) ConcreteVisitor1 + Visit(ConcreteElement1 element) + Visit(ConcreteElement2 element) ConcreteVisitor2 + Visit(ConcreteElement1 element) + Visit(ConcreteElement2 element) public AcceptVisitor(IVisitor visitor) { visitor.Visit(this); }
Use Case 
A la crêperie • Au menu, on trouve crêpe et gaufre. • On peut y ajouter du chocolat, des fraises, de la chantilly … • Le prix de la crêpe chocolat banane = prix crêpe + prix chocolat + prix banane
A la crêperie • Au menu, crêpe et gaufre avec supplément chocolat, bananes, fraises, chantilly … Crepe + GetPrice() Waffle + GetPrice() <<Interface>> IDessert + GetPrice() Extra + GetPrice() Chocolate + GetPrice() Chantilly + GetPrice() Strawberry + GetPrice() dessert public GetPrice() { return this.price + this.dessert.GetPrice(); }
Decorator • Ajouter dynamiquement des fonctionnalités supplémentaires à un objet. <<Interface>> IComponent + DoSomething() ConcreteComponent + DoSomething() <<Interface>> IDecorator + DoSomething() Decorator + DoSomething() public Decorator(IComponent component) { this.component = component; } public DoSomething() { ... this.component.DoSomething-); ... }
Decorator – use case • Ajouter dynamiquement des fonctionnalités à un objet sans modifier son interface • Gérer des fonctionnalités qui peuvent être retirées dynamiquement • Eviter l’héritage complexe <<Interface>> IComponent + DoSomething() ConcreteComponent + DoSomething() <<Interface>> IDecorator + DoSomething() Decorator + DoSomething() public Decorator(IComponent component) { this.component = component; } public DoSomething() { ... this.component.DoSomething-); ... }
Decorator – attention • Ce pattern ne traite pas l’ordre de composition ou de fabrication <<Interface>> IComponent + DoSomething() ConcreteComponent + DoSomething() <<Interface>> IDecorator + DoSomething() Decorator + DoSomething() public Decorator(IComponent component) { this.component = component; } public DoSomething() { ... this.component.DoSomething-); ... }
Use Case 
Au roi du burger • Constituer son burger • Choisir le pain et ajouter des ingrédients avec type de portion • Légère • Normal • Extra
Builder • Construire des objets complexes sans préoccuper le client des différentes implémentations Director + Construct() <<Interface>> IBuilder + BuildFirstPart() + BuildSecondPart() + GetProduct() ConcreteBuilder + BuildFirstPart() + BuildSecondPart() + GetProduct() Product
Builder – use case • Le client a besoin de construire un objet complexe sans connaitre son implémentation • Le client a besoin de construire des objets complexes ayant plusieurs implémentations ou représentations Director + Construct() <<Interface>> IBuilder + BuildFirstPart() + BuildSecondPart() + GetProduct() ConcreteBuilder + BuildFirstPart() + BuildSecondPart() + GetProduct() Product
Builder – attention • Quand il s’agit d’une construction step by step • Complexité du code Director + Construct() <<Interface>> IBuilder + BuildFirstPart() + BuildSecondPart() + GetProduct() ConcreteBuilder + BuildFirstPart() + BuildSecondPart() + GetProduct() Product
Use Case 
Un peu de mathématiques • Réalisez l’expression suivante (4 - 5) * 2 • L’idée est de pouvoir réaliser plusieurs opérations à la suite ((4 - 5) * 2) + (4 * (1 + 6)) 4 5 -1 - 2 -2 * 1 6 4 + 7 28 * + 26
Un peu de mathématiques Operand + Evaluate() Operator + Evaluate() <<Interface>> IExpression + Evaluate() PlusOperator + Evaluate() MinusOperator + Evaluate() 2 #LeftExpression #RightExpression public Operand(double value) { this.operand = value; } public double Evaluate() { return this.operand; } public double Evaluate() { return this.leftExpression.Evaluate() + this.rightExpression.Evaluate(); } public Operator(IExpression leftExpression, IExpression rightExpression) { this.leftExpression = leftExpression; this.rightExpression = rightExpression; } public abstract double Evaluate(); public double Evaluate() { return this.leftExpression.Evaluate() - this.rightExpression.Evaluate(); }
Interpreter • Définir une représentation de grammaire pour interpréter des expressions TerminalExpression + Interpret(Context) NonTerminalExpression + Interpret(Context) <<Interface>> IExpression + Interpret(Context) NonTerminalExpression1 + Interpret(Context) NonTerminalExpression2 + Interpret(Context)
Interpreter – use cases • Interpréter des expressions représentées sous forme d’arbres syntaxiques • Quand la grammaire des expressions est simple • L’évaluation n’a pas besoin d’être rapide • Si la grammaire est complexe, il vaut mieux utiliser un analyseur syntaxique • Si l’évaluation doit être rapide, il vaut mieux utiliser un compilateur TerminalExpression + Interpret(Context) NonTerminalExpression + Interpret(Context) <<Interface>> IExpression + Interpret(Context) NonTerminalExpression1 + Interpret(Context) NonTerminalExpression2 + Interpret(Context)
Use Case 
Comportement graphique des sites web
Comportement graphique des sites web • La modification d’une valeur d’un widget peut conduire à modifier l’aspect d’autres widget : • Visible ou masqué • Changement des valeurs d’un menu • Changement du format des valeurs • Inconvénient • Chaque objet doit connaitre tous les objets dépendants • La réutilisabilité des objets est réduite Widget 1 Widget 2 Widget 3 Widget 4 Widget 5 Widget 6
Mediator • Construire un objet dont la vocation est la gestion et le contrôle des interactions dans un ensemble d’objets sans que ses éléments doivent se connaitre mutuellement. <<Interface>> Mediator + DoSomething() <<Interface>> Element ConcreteElement1 ConcreteElement1 ConcreteMediator
Mediator – use cases • Un système est formé d’un ensemble d’objets basé sur une communication complexe conduisant à associer de nombreux objets entre eux • Les objets d’un système sont difficiles à réutiliser car ils possèdent de nombreuses associations avec d’autres objets • La modularité d’un système est médiocre, obligeant dans le cas d’une adaptation d’une partie du système à écrire de nombreuses sous classes. <<Interface>> Mediator + DoSomething() <<Interface>> Element ConcreteElement1 ConcreteElement1 ConcreteMediator
Use Case 
Distributeur de billets Source : https://sourcemaking.com/design_patterns/chain_of_responsibility
Chain of responsibility • Une chaine d’objets tel que si un objet ne peut pas répondre à une requête, il puisse la transmettre à son successeur jusqu’à ce que l’un des objets de la chaine y réponde. Handler + HandleRequest() successor ConcreteHandler1 + HandleRequest() ConcreteHandler1 + HandleRequest() Client
Chain of responsibility – use cases • Une chaine d’objets gère une requête selon un ordre qui es défini dynamiquement • La façon dont une chaine d’objets gère une requête ne doit pas être connue par le client Handler + HandleRequest() successor ConcreteHandler1 + HandleRequest() ConcreteHandler1 + HandleRequest() Client
Use Case 
Composer son PC • Choisir les options • Taille écran : 11’, 16’ … • Processeur : i5, i7 … • Mémoire RAM : 12 Go, 16 Go … • Taille du disque dur : 1To, SSD … • Carte vidéo : NVIDIA, AMD … • Casque : USB, Bluetooth … • Souris : filaire, sans fil… • Sac : à dos, sacoche … • Clavier : Azerty, Querty • Chaque option a un prix • Le prix du PC = prix de base (300€) + somme des options
Flyweight • Permet de partager de façon efficace un ensemble important d’objets de granularité fine FlyweightFabric + GetFlyweight(key) Flyweight - intrinsicState + Operation(extrinsicState) Client if(flyweights.ContainsKey(key)) { return flyweights[key]; } else { var newFlyweight = new Flyweight(); flyweights.Add(key, newFlyweight); return newFlyweight; }
Flyweight – use cases • Le système utilise un grand nombre d’objets • Le stockage des objets est couteux à cause d’une grande quantité • Il existe de nombreux ensembles d’objets qui peuvent être remplacés par quelques objets partagés une fois qu’une partie de leur état est rendue extrinsèque FlyweightFabric + GetFlyweight(key) Flyweight - intrinsicState + Operation(extrinsicState) Client if(flyweights.ContainsKey(key)) { return flyweights[key]; } else { var newFlyweight = new Flyweight(); flyweights.Add(key, newFlyweight); return newFlyweight; }
Use Case 
Chez le concessionnaire • Un client veut passer une commande pour une voiture • Il a le choix de payer au comptant ou à crédit
Chez le concessionnaire • Un client veut passer une commande pour une voiture • Il a le choix de payer au comptant ou à crédit OrderCreator + CreateNewOrder() - CreateOrder() : Order Order + Pay(); + IsValid() : bool SpotOrder + Pay(); + IsValid() : bool ForwardOrder + Pay(); + IsValid() : bool public void CreateNewOrder() { Order order= CreateOrder(); if(order.IsValid()) { order.Pay(); } } private Order CreateOrder() { if(paymentType == PaymentType.Spot) { return new SpotOrder(); } else { return new ForwardOrder(); } }
Chez le concessionnaire BaseOrderCreator + CreateNewOrder() # CreateOrder() : Order SpotOrderCreator # CreateOrder() : Order Order + Pay(); + IsValid() : bool SpotOrder + Pay(); + IsValid() : bool ForwardOrder + Pay(); + IsValid() : bool ForwardOrderCreator # CreateOrder() : Order public void CreateNewOrder() { Order order= CreateOrder(); if(order.IsValid()) { order.Pay(); } } protected Order CreateOrder() { return new SpotOrder(); } protected Order CreateOrder() { return new ForwardOrder(); }
AbstractCreator + CreateProduct() : IProduct Creator + CreateProduct() : IProduct IProduct Product Factory Method • Introduire une méthode abstraite de création d’un objet en reportant aux sous-classes concrètes la création effective
AbstractCreator + CreateProduct() : IProduct Creator + CreateProduct() : IProduct IProduct Product Factory Method – use cases • Une classe ne connait que les classes abstraites des objets avec lesquels elle possède des relations • Une classe veut transmettre à ses sous-classes les choix d’instanciation en profitant du mécanisme de polymorphisme
Use Case 
Période des soldes • Le responsable du magasin a besoin d’appliquer et annuler une réduction sur un produit • Aujourd’hui -20% sur le prix initial • Demain -10% supplémentaires => -30% en tout • Le lendemain annuler le -10% => -20% en tout
Command • Permet de transformer une requête en un objet pour faciliter les opérations comme l’annulation ou la mise en file des requêtes et leur suivi Command + Execute() <<Interface>> ICommand + Execute() Invoker + SetCommand(ICommand) + ExecuteCommand() IReceiver + Action() receiver.Action();
Command – use cases • Un objet doit être paramétré par un traitement à réaliser • Les commandes • À stocker dans une file • À exécuter à tout moment ou plusieurs fois • À Annuler • À tracer dans un fichier de log Command + Execute() <<Interface>> ICommand + Execute() Invoker + SetCommand(ICommand) + ExecuteCommand() IReceiver + Action() receiver.Action();
Command – attention • Les commandes peuvent être regroupées sous la forme d’une transaction (un ensemble ordonné de commandes qui agissent sur l’état d’un système, si l’une est annulée tout l’ensemble l’est aussi) Command + Execute() <<Interface>> ICommand + Execute() Invoker + SetCommand(ICommand) + ExecuteCommand() IReceiver + Action() receiver.Action();

Contenu connexe

PDF
Support de cours angular
parENSET, Université Hassan II Casablanca
 
PDF
Tdd en action - refactoring
parEric Mignot
 
PDF
【関東GPGPU勉強会#2】OpenCVのOpenCL実装oclMat
parYasuhiro Yoshimura
 
PPTX
Writing php extensions in golang
pardo_aki
 
PPTX
凡人の凡人による凡人のためのデザインパターン第一幕 Public
parbonjin6770 Kurosawa
 
PDF
Angular Directives
pariFour Technolab Pvt. Ltd.
 
PDF
認証の標準的な方法は分かった。では認可はどう管理するんだい？ #cmdevio
par都元ダイスケ Miyamoto
 
PPT
Design Patterns
parMehdi Mehni
 
Support de cours angular
parENSET, Université Hassan II Casablanca
 
Tdd en action - refactoring
parEric Mignot
 
【関東GPGPU勉強会#2】OpenCVのOpenCL実装oclMat
parYasuhiro Yoshimura
 
Writing php extensions in golang
pardo_aki
 
凡人の凡人による凡人のためのデザインパターン第一幕 Public
parbonjin6770 Kurosawa
 
Angular Directives
pariFour Technolab Pvt. Ltd.
 
認証の標準的な方法は分かった。では認可はどう管理するんだい？ #cmdevio
par都元ダイスケ Miyamoto
 
Design Patterns
parMehdi Mehni
 

Similaire à Design patterns

PDF
Cours design pattern m youssfi partie 1 introduction et pattern strategy
parENSET, Université Hassan II Casablanca
 
PPT
Design poo togo_jug_final
parDuchess France
 
PPT
Design poo togo_jug_final
paragnes_crepet
 
PPTX
OOP & Design Pattern - Algiers Developers Meetup August 2015
parTarik Zakaria Benmerar
 
PPTX
OOP and Design Patterns
parAlgiers Tech Meetup
 
PPTX
Design patterns et Design Emergeant - Micro Days - Modern Software Developmen...
parTarik Zakaria Benmerar
 
PPT
Design Patterns Java
parVINOT Bernard
 
PDF
Designs Patterns
parJean David Olekhnovitch
 
PDF
DesignPatternsISI.pdf
parandre543581
 
PPTX
Conception-Logicielle-Moderne-Fondements-et-Bonnes-Pratiques.pptx
parKhoussNgom
 
PDF
Design patterns
parEric Toguem
 
PPTX
Presentation DESIGN PATTERNS DE CREATION.pptx
pardavidZorom
 
PDF
softCours design pattern m youssfi partie 9 creation des objets abstract fact...
parENSET, Université Hassan II Casablanca
 
PPTX
Patrons de conception
parAmine MAAROUFI
 
PPT
U M L Analyse Et Conception Objet
parAmine Chkr
 
PPT
Uml
parVINOT Bernard
 
PPT
Patrons de creation
paromri med
 
PDF
Design Patterns (2003)
parPascal Roques
 
PDF
Design patterns - Exemples en Java
parOussama BEN KHIROUN
 
PPTX
Design patterns gof fr
parIt Academy
 
Cours design pattern m youssfi partie 1 introduction et pattern strategy
parENSET, Université Hassan II Casablanca
 
Design poo togo_jug_final
parDuchess France
 
Design poo togo_jug_final
paragnes_crepet
 
OOP & Design Pattern - Algiers Developers Meetup August 2015
parTarik Zakaria Benmerar
 
OOP and Design Patterns
parAlgiers Tech Meetup
 
Design patterns et Design Emergeant - Micro Days - Modern Software Developmen...
parTarik Zakaria Benmerar
 
Design Patterns Java
parVINOT Bernard
 
Designs Patterns
parJean David Olekhnovitch
 
DesignPatternsISI.pdf
parandre543581
 
Conception-Logicielle-Moderne-Fondements-et-Bonnes-Pratiques.pptx
parKhoussNgom
 
Design patterns
parEric Toguem
 
Presentation DESIGN PATTERNS DE CREATION.pptx
pardavidZorom
 
softCours design pattern m youssfi partie 9 creation des objets abstract fact...
parENSET, Université Hassan II Casablanca
 
Patrons de conception
parAmine MAAROUFI
 
U M L Analyse Et Conception Objet
parAmine Chkr
 
Uml
parVINOT Bernard
 
Patrons de creation
paromri med
 
Design Patterns (2003)
parPascal Roques
 
Design patterns - Exemples en Java
parOussama BEN KHIROUN
 
Design patterns gof fr
parIt Academy
 

Plus de Dorra BARTAGUIZ

PDF
Improving feature flip implementation to achieve flow
parDorra BARTAGUIZ
 
PDF
IA & Craft : Découvrez 6 impacts business concrets, études à l'appui
parDorra BARTAGUIZ
 
PDF
Sortons de la pyramide pour construire une strategie de test
parDorra BARTAGUIZ
 
PDF
DDD pour une meilleure qualité du produit
parDorra BARTAGUIZ
 
PDF
Veille tech efficace : comment rester à jour sans y laisser son énergie !
parDorra BARTAGUIZ
 
PDF
Elevating Tactical DDD Patterns Through Object Calisthenics
parDorra BARTAGUIZ
 
PDF
Elevating Tactical DDD Patterns Through Object Calisthenics
parDorra BARTAGUIZ
 
PDF
Améliorer l'implémentation du feature flipping
parDorra BARTAGUIZ
 
PDF
Sortons de la pyramide pour construire une stratégie de test
parDorra BARTAGUIZ
 
PDF
Living documentation au service de l'agilité
parDorra BARTAGUIZ
 
PDF
Devs, let's reclaim DDD!
parDorra BARTAGUIZ
 
PDF
Rendons le DDD aux devs
parDorra BARTAGUIZ
 
PDF
S'améliorer sans s'épuiser
parDorra BARTAGUIZ
 
PDF
Les classes abstraites c’est fini (et c’est la faute à TDD)
parDorra BARTAGUIZ
 
PDF
Slim down diet and tdd
parDorra BARTAGUIZ
 
PDF
Slim down diet_ and tdd
parDorra BARTAGUIZ
 
Improving feature flip implementation to achieve flow
parDorra BARTAGUIZ
 
IA & Craft : Découvrez 6 impacts business concrets, études à l'appui
parDorra BARTAGUIZ
 
Sortons de la pyramide pour construire une strategie de test
parDorra BARTAGUIZ
 
DDD pour une meilleure qualité du produit
parDorra BARTAGUIZ
 
Veille tech efficace : comment rester à jour sans y laisser son énergie !
parDorra BARTAGUIZ
 
Elevating Tactical DDD Patterns Through Object Calisthenics
parDorra BARTAGUIZ
 
Elevating Tactical DDD Patterns Through Object Calisthenics
parDorra BARTAGUIZ
 
Améliorer l'implémentation du feature flipping
parDorra BARTAGUIZ
 
Sortons de la pyramide pour construire une stratégie de test
parDorra BARTAGUIZ
 
Living documentation au service de l'agilité
parDorra BARTAGUIZ
 
Devs, let's reclaim DDD!
parDorra BARTAGUIZ
 
Rendons le DDD aux devs
parDorra BARTAGUIZ
 
S'améliorer sans s'épuiser
parDorra BARTAGUIZ
 
Les classes abstraites c’est fini (et c’est la faute à TDD)
parDorra BARTAGUIZ
 
Slim down diet and tdd
parDorra BARTAGUIZ
 
Slim down diet_ and tdd
parDorra BARTAGUIZ
 

Design patterns

  • 1.
  • 2.
    Qui suis-je ? •Dorra BARTAGUIZ • Software craftswoman • Tech lead • Coach technique • Peu importe le langage • .Net, java, php, python, js dorra.bartaguiz@outlook.com
  • 3.
    Programme Du code C#à faire/factoriser Contexte Problématique Extraire le design pattern
  • 4.
  • 5.
    Design pattern -Définition • Modèle de conception • Décrit les cas d’utilisation • Sert d’abstraction au modèle d’implémentation • Intension, motivation, solution • Une solution à un problème générique
  • 6.
    Premier exemple • Projetà récupérer de GitHub • https://github.com/iAmDorra/DesignPatterns Folder + Name : String File + Name : String contains contains
  • 7.
    Solution & Projet •Définir le projet (ou les) de démarrage • Références d’un projet • Un autre projet • Une librairie du Framework • Un composant COM • … Project 1 Project 2 References Solution Project 3 References Project 4 2 1 1' 3 References x Build order
  • 8.
    Premier exemple • Contexte: • Un dossier peut contenir des fichiers et des dossiers Folder + Name : String File + Name : String contains contains
  • 9.
    Premier exemple • Inconvénients: • Pour connaitre le contenu de Folder, il faut parcourir les deux listes Folder + Name : String File + Name : String contains contains
  • 10.
    Premier exemple • Pourconnaitre le contenu de Folder, il faut parcourir une seule collection Folder + Name : String File + Name : String <<Interface>> IElement + Name : String
  • 11.
    Premier exemple • Caractéristiques •Eviter la duplication • Extensible => Pattern « Composite » Folder + Name : String File + Name : String contains contains Folder + Name : String File + Name : String <<Interface>> IElement + Name : String
  • 12.
    Exercice • Ajouter unlien (Link) • Un lien peut référencer un fichier ou un dossier (pas les deux) • Un dossier peut contenir des liens Folder + Name : String File + Name : String <<Interface>> IElement + Name : String
  • 13.
  • 14.
    SOLID • S RP: Single Responsibility Principle • O CP : Open Close Principle • L SP : Liskov Substitution Principle • I SP : Interface Separation Principle • D IP : Dependency Inversion Principle
  • 15.
    Classification des patterns •GoF (Gang of four) classification • Creational patterns (de construction) • Behavior patterns (de comportement) • Structural patterns (de structuration)
  • 16.
    Revenons à nosmoutons 
  • 17.
    Composite • Permettre àun client d’interagir avec un objet sans connaitre la profondeur de sa composition • Limiter les dépendances entre les classes concrètes • Eviter la duplication • Extensible Folder + Name : String File + Name : String <<Interface>> IElement + Name : String
  • 18.
    Composite – usecases • Il est nécessaire de représenter des hiérarchies de composition • Les clients de la composition doivent ignorer s’ils communiquent avec des objets composés ou non Folder + Name : String File + Name : String <<Interface>> IElement + Name : String
  • 19.
  • 20.
    Le système solaire •Il est composé de : • Le soleil • Des planètes • Autres étoiles et objets célestes
  • 21.
    Le système solaire Sun -instance : Sun + GetInstance() : Sun private static Sun instance = new Sun(); private Sun() { } public static Sun GetInstance() { return instance; }
  • 22.
    Singleton • Assurer qu’uneclasse ne possède qu’une seule instance et de fournir une méthode de classe unique retournant cette instance Singleton - instance : Singleton + GetInstance() : Singleton private static Singleton instance = new Singleton(); private Singleton() { } public static Singleton GetInstance() { return instance; }
  • 23.
    Singleton – usecases • Il ne doit y avoir qu’une seule instance • Cette instance n’est accessible qu’à travers une méthode de classe • Eviter une variable globale Singleton - instance : Singleton + GetInstance() : Singleton private static Singleton instance = new Singleton(); private Singleton() { } public static Singleton GetInstance() { return instance; }
  • 24.
    Singleton – usecases On peut avoir une version lazy du singleton Singleton - instance : Singleton + GetInstance() : Singleton private static Singleton instance; public static Singleton GetInstance() { if(instance == null) instance = new Singleton(); return instance }
  • 25.
    Singleton – attention •Si on est en multithreading, ajout un lock pour l’instance • Eviter les méthodes qui set l’instance à null Singleton - instance : Singleton + GetInstance() : Singleton + Reset() public static Singleton GetInstance() { if(instance == null) instance = new Singleton(); return instance } public void Reset() { instance = null; } var first = Singleton.GetInstance(); // first pointe donc sur un objet en mémoire first .Reset(); var second = Singleton.GetInstance(); // => on a donc deux instances en mémoire
  • 26.
  • 27.
    Appel au serviceclient • Un client achète un article sur un site et paye par carte bancaire • Il veut changer l’adresse de livraison et rajouter une option dans l’article • Le changement d’adresse est au service de facturation • L’ajout de l’option est au service de commande • Il appelle le service client qui se charge de tout
  • 28.
    Appel au serviceclient CustomerService + UpdateAdress(Client client, Adress newAdress) + AddOption(Order order, Option option) Billing + AddOption(Order order, Option option) + Edit(Order order) Ordering +UpdateAdress(Client client, Adress newAdress) Uses public void UpdateAdress(Client client, Adress newAdress) { ordering.UpdateAdress(client, newAdress); } public void AddOption(Order order, Option option) { billing.AddOption(order, option); }
  • 29.
    Façade • Créer uneinterface unifiée au sous-système • Un objet composé de plusieurs services Facade + RunMethod1(parameter1, parameter2) + RunMethod3() + RunMethod4(parameter3) Service3 + RunMethod4(parameter3) + RunMethod5(parameter) Service2 + RunMethod3() Service1 + RunMethod1(parameter1, parameter2) + RunMethod2()
  • 30.
    Façade – usecases • Dissimuler/faciliter au client la complexité des activités internes • Besoin de contrôler les modes d’accès aux composants • Un point d’entrée au sous-système Facade + RunMethod1(parameter1, parameter2) + RunMethod3() + RunMethod4(parameter3) Service3 + RunMethod4(parameter3) + RunMethod5(parameter) Service2 + RunMethod3() Service1 + RunMethod1(parameter1, parameter2) + RunMethod2()
  • 31.
    Façade – attention •Fort couplage • Degré de dépendance d’un module vis-à- vis d’un autre • Faible cohésion • Degré de cohérence des responsabilités d’un module Facade + RunMethod1(parameter1, parameter2) + RunMethod3() + RunMethod4(parameter3) Service3 + RunMethod4(parameter3) + RunMethod5(parameter) Service2 + RunMethod3() Service1 + RunMethod1(parameter1, parameter2) + RunMethod2()
  • 32.
  • 33.
    Compresser des données •On a besoin de compresser des données • Codage par répétition • AAA0000111FF => 3A40312F • Codage entropique (de Huffman ou arithmétique) • Pattern => 000 001 11 11 010 011 10
  • 34.
    Compresser des données Compressor +string Compress(string data) <<Interface>> ICompressor + string Compress(string data) public string Compress(string data) { switch (this.compressionType) { case CompressionType.Repetition: return CompressWithRepetitionAlgo(data); case CompressionType.Entropic: return CompressWithEntropicAlgo(data); case CompressionType.ByDictionary: return CompressByDictionaryAlgo(data); default: return data; } }
  • 35.
    Compresser des données RepetitionCompressor +string Compress(string data) <<Interface>> ICompressor + string Compress(string data) EntropicCompressor + string Compress(string data) Context - compressor : ICompressor + string Compress(string data) ByDictionaryCompressor + string Compress(string data) public string Compress(string data) { compressor.Compress(data); }
  • 36.
    Strategy • Adapter lecomportement d’un objet en fonction d’un besoin sans changer les interactions de cet objet avec les clients • Représenter les comportements variables sous forme de classes • Les comportements/algorithmes sont interchangeables ConcreteStrategyA + Calculate() <<Interface>> Strategy + Calculate() ConcreteStrategyB + Calculate() Context + Execute() void Execute() { strategy.Calculate(); }
  • 37.
    Strategy – usecases • Besoin d’implémenter plusieurs comportements pour un traitement • Protéger les variations en séparant les parties variantes et invariantes ConcreteStrategyA + Calculate() <<Interface>> Strategy + Calculate() ConcreteStrategyB + Calculate() Context + Execute() void Execute() { strategy.Calculate(); }
  • 38.
    Strategy – attention •Quand les contextes sont responsables du choix de la stratégie ConcreteStrategyA + Calculate() <<Interface>> Strategy + Calculate() ConcreteStrategyB + Calculate() Context + Execute() void Execute() { strategy.Calculate(); }
  • 39.
  • 40.
    Chez le concessionnaire •Le concessionnaire gère les commandes issues de client de la France et du Luxembourg. • La différence entre les commandes concerne le calcul de la TVA • France : TVA = 19,6% • Luxembourg : TVA = 12% pour les prestations et 15% pour le matériel
  • 41.
    Chez le concessionnaire •Montant = HT + TVA <<Interface>> IOrder +CalculateAmount() FrenchOrder -preTaxAmount +CalculateAmount() LuxembourgishOrder -preTaxServiceAmount -preTaxMaterialAmount +CalculateAmount() public double CalculateAmount() { var vatAmount = preTaxAmount * 0.196; var amount = preTaxAmount + vatAmount; return amount; } public double CalculateAmount() { var vatAmount = preTaxServiceAmount * 0.12 + preTaxMaterialAmount * 0.15; var preTaxAmount = preTaxServiceAmount + preTaxMaterialAmount; var amount = preTaxAmount + vatAmount; return amount; }
  • 42.
    Chez le concessionnaire •Montant = HT + TVA • Extraire les méthodes • Mieux voir les factorisations futures <<Interface>> IOrder +CalculateAmount() FrenchOrder -preTaxAmount +CalculateAmount() LuxembourgishOrder -preTaxServiceAmount -preTaxMaterialAmount +CalculateAmount() public double CalculateAmount() { var amount = CalculatePreTaxAmount()+ CalculateVat(); return amount; } private double CalculateVat() { return preTaxAmount * 0.196; } private double CalculatePreTaxAmount() { return preTaxAmount; } public double CalculateAmount() { var amount = CalculatePreTaxAmount()+ CalculateVat(); return amount; } private double CalculateVat() { return preTaxServiceAmount * 0.12 + preTaxMaterialAmount * 0.15; } private double CalculatePreTaxAmount() { return preTaxServiceAmount + preTaxMaterialAmount; }
  • 43.
    Chez le concessionnaire •Montant = HT + TVA • Factoriser le comportement dans la classe de base • Implémenter les spécificités dans les classes filles <<Interface>> IOrder +CalculateAmount() FrenchOrder -preTaxAmount #CalculateVat() #CalculatePreTaxAmount() LuxembourgishOrder -preTaxServiceAmount -preTaxMaterialAmount #CalculateVat() #CalculatePreTaxAmount() <<Abstract>> BaseOrder +CalculateAmount() #CalculateVat() #CalculatePreTaxAmount() protected override double CalculateVat() { return preTaxAmount * 0.196; } protected override double CalculatePreTaxAmount() { return preTaxAmount; } protected override double CalculateVat() { return preTaxServiceAmount * 0.12 + preTaxMaterialAmount * 0.15; } protected override double CalculatePreTaxAmount() { return preTaxServiceAmount + preTaxMaterialAmount; } public double CalculateAmount() { return CalculateVat() + CalculatePreTaxAmount(); } protected abstract double CalculateVat(); protected abstract double CalculatePreTaxAmount();
  • 44.
    Template method • Reporteraux filles certaines étapes d’un traitement • Les étapes sont implémentées dans les classes filles ConcreteClass #Operation1() #Operation2() <<Abstract>> BaseClass +TemplateMethod() #Operation1() #Operation2() public void TemplateMethod() { ... Operation1(); ... Operation2(); ... } protected abstract void Operation1(); protected abstract void Operation2(); protected override void Operation1() { ... } protected override void Operation2() { ... }
  • 45.
    Template method –use cases • Deux classes ou plusieurs partagent du code identique • Les parties spécifiques déplacées dans les filles • Un algorithme avec une partie invariable et des parties spécifiques à différents objets ConcreteClass #Operation1() #Operation2() <<Abstract>> BaseClass +TemplateMethod() #Operation1() #Operation2() public void TemplateMethod() { ... Operation1(); ... Operation2(); ... } protected abstract void Operation1(); protected abstract void Operation2(); protected override void Operation1() { ... } protected override void Operation2() { ... }
  • 46.
  • 47.
    L’usine à chaussures •L’usine crée • Des chaussures de ville, des sandales • En cuir ou synthétiques ShoeCreator + CreateLeatherShoe() + CreateLeatherSandal() + CreateSyntheticShoe() + CreateSyntheticSandal() IShoe -type Client Sandal -type StreetShoe -type public StreetShoe CreateLeatherShoe() { return new StreetShoe(ShoeType.Leather); } public Sandal CreateSyntheticSandal() { return new Sandal(ShoeType.Synthetic); }
  • 48.
    L’usine à chaussures ShoeCreator +CreateShoe() + CreateSandal() IShoe Client Sandal StreetShoe LeatherFabric + CreateShoe() + CreateSandal() SyntheticFabric + CreateShoe() + CreateSandal() LeatherSandal SyntheticSandal LeatherStreetShoe SyntheticStreetShoe public StreetShoe CreateShoe() { return new LeatherStreetShoe(); } public Sandal CreateSandal() { return new LeatherSandal(); } public StreetShoe CreateShoe() { return new SyntheticStreetShoe(); } public Sandal CreateSandal() { return new SyntheticSandal(); }
  • 49.
    Abstract factory • Créerdes objets regroupés en familles sans devoir connaître les classes concrètes destinées à la création de ces objets • Configuration flexible • Les implémentations doivent changer en fonction de certains paramètres AbstractFabric + CreateProductA() + CreateProductB() Client ProductA ProductB ConcreteFabric1 + CreateProductA() + CreateProductB() ConcreteFabric2 + CreateProductA() + CreateProductB() ProductA1 ProductA2 ProductB1 ProductB2
  • 50.
    Abstract factory –use cases • Un système utilisant des produits a besoin d’être indépendant de la façon dont ces produits sont créés et regroupés • Un système est paramétré par plusieurs familles de produits qui peuvent évoluer AbstractFabric + CreateProductA() + CreateProductB() Client ProductA ProductB ConcreteFabric1 + CreateProductA() + CreateProductB() ConcreteFabric2 + CreateProductA() + CreateProductB() ProductA1 ProductA2 ProductB1 ProductB2
  • 51.
    Abstract factory -attention • Si une règle de gestion exige de ne pas pouvoir créer des sandales en synthétique par exemple, ce pattern ne correspond pas car on va implémenter la méthode CreateSandal pour le synthétique • Risque de créer des objets incompatibles entre eux AbstractFabric + CreateProductA() + CreateProductB() Client ProductA ProductB ConcreteFabric1 + CreateProductA() + CreateProductB() ConcreteFabric2 + CreateProductA() + CreateProductB() ProductA1 ProductA2 ProductB1 ProductB2
  • 52.
  • 53.
    Faire du shopping •Un client commande des articles sur internet • Statuts de la commande : • En cours : le client est en train de choisir les articles • Validée : le client valide et paye la commande • Livrée : le client reçoit les articles
  • 54.
    Faire du shopping •Inconvénients • Il faut gérer tous les statuts dans les méthodes • Les transitions des statuts sont gérées par la commande Order - state - items + AddItem() + RemoveItem() + NextState() public void AddItem(Item item) { if(state == InProgress) { items.Add(item); } else { throw new System.NotSupportedException(); } } public void RemoveItem(Item item) { if(state == InProgress || state == Validated) { items.Remove(item); } else { throw new System.NotSupportedException(); } }
  • 55.
    Faire du shopping •Inconvénients • Il faut gérer tous les statuts dans les méthodes • Les transitions des statuts sont gérées par la commande • Nouvel objet à chaque modif de statut Order -state -items +AddItem() +RemoveItem() +NextState() InprogressOrder +AddItem() +RemoveItem() ValidatedOrder +AddItem() +RemoveItem() DeliveredOrder +AddItem() +RemoveItem() public void AddItem(Item item) { throw new NotSupportedException(); } public void RemoveItem(Item item) { throw new NotSupportedException(); } public void AddItem(Item item) { throw new NotSupportedException(); } public void RemoveItem(Item item) { items.Remove(item); } public void AddItem(Item item) { items.Add(item); } public void RemoveItem(Item item) { items.Remove(item); }
  • 56.
    Faire du shopping •Inconvénients • Il faut gérer tous les statuts dans les méthodes • Les transitions des statuts sont gérées par la commande • Nouvel objet à chaque modif de statut OrderStatus +AddItem() +RemoveItem() InprogressStatus +AddItem() +RemoveItem() ValidatedStatus +AddItem() +RemoveItem() DeliveredStatus +AddItem() +RemoveItem() Order -state -items +AddItem() +RemoveItem() +NextState() public void AddItem(Item item) { throw new NotSupportedException(); } public void RemoveItem(Item item) { throw new NotSupportedException(); } public void AddItem(Item item) { throw new NotSupportedException(); } public void RemoveItem(Item item) { items.Remove(item); } public void AddItem(Item item) { items.Add(item); } public void RemoveItem(Item item) { items.Remove(item); } public void AddItem(Item item) { state.AddItem(item); } public void RemoveItem(Item item) { state.RemoveItem(item); }
  • 57.
    State • Permet àun objet (Context) d’adapter son comportement en fonction de son état interne Context +Request() State +Handle() ConcreteStateA +Handle() ConcreteStateB +Handle() Request() { state.Handle(); }
  • 58.
    State – usecases • Le comportement d’un objet dépend de son état • L’implémentation par des instructions conditionnelles est trop complexe Context +Request() State +Handle() ConcreteStateA +Handle() ConcreteStateB +Handle() Request() { state.Handle(); }
  • 59.
    State – attention •Ne pas implémenter si deux états (simples) Context +Request() State +Handle() ConcreteStateA +Handle() ConcreteStateB +Handle() Request() { state.Handle(); }
  • 60.
  • 61.
    Comparateur d'hôtels • J’aicréé un service de comparaison des hôtels du coin • Je veux cherche des clients potentiels pour mon service Comparator + GetAvailableRooms(Date) : List<RoomPrice> <<Interface>> IComparator + GetAvailableRooms(Date) : List<RoomPrice>
  • 62.
    Comparator + GetAvailableRooms(Date) :List<RoomPrice> Client <<Interface>> IComparator + GetRoomAvailailities(Date) : List<RoomAvailability> <<Interface>> IComparator + GetAvailableRooms(Date) : List<RoomPrice> Comparateur d'hôtels • Le client impose un contrat de service qui lui correspond ?
  • 63.
    Comparateur d'hôtels • Leclient impose un contrat de service qui lui correspond Comparator + GetAvailableRooms(Date) : List<RoomPrice> Client <<Interface>> IComparator + GetRoomAvailailities(Date) : List<RoomAvailability> <<Interface>> IComparator + GetAvailableRooms(Date) : List<RoomPrice> ComparatorAdaptor + GetRoomAvailailities(Date) : List<RoomAvailability>
  • 64.
    Adapter • Convertir uneclass existante en une interface attendue par les clients également existants afin qu’ils puissant travailler ensemble Adaptee + SpecificRequest() Client <<Interface>> ITarget + Request() Adapter + Request() adaptee.SpecificRequest()
  • 65.
    Adapter – usecases • Intégrer dans un système un objet dont l’interface ne correspond pas à l’interface requise au sein de ce système • Fournir des interfaces multiples à un objet lors de sa conception Adaptee + SpecificRequest() Client <<Interface>> ITarget + Request() Adapter + Request() adaptee.SpecificRequest()
  • 66.
    Adapter – attention •Il y aura autant d’adaptateurs que de fournisseur Adaptee + SpecificRequest() Client <<Interface>> ITarget + Request() Adapter + Request() adaptee.SpecificRequest()
  • 67.
  • 68.
    Compter le nombrede LIKE • Dans mon application, j’ai un service pour liker mon produit • Créer un service de comptage LikeCounter + CountLikes() ProductAnalysis + LikeProduct()
  • 69.
    Compter le nombrede LIKE LikeCounter + Update(int) <<Interface>> ILikeCounter + Update(int) ProductAnalysis - List<ILikeCounter> counters + Add(ILikeCounter) + LikeProduct() public void Add(ILikeCounter counter) { counters.Add(counter); } public void LikeProduct() { likesNumber ++; foreach(var counter in this.counters) { counter.Update(likesNumber); } } public LikeCounter(ProductAnalysis product) { product.Add(this); } public void Update(int number) { Console.WriteLine(number); }
  • 70.
    Observer • Permet auxobservateurs de mettre à jour leur état quand le sujet est modifié <<abstract>> Subject + Add(Observer) + Remove(Observer) + Notify() ConcretSubject - subjectState + GetState() <<abstract>> Observer + Update() ConcreteObserver - observerState + Update() subject observer return subjectState; public void Add(Observer observer) { this.observers.Add(observer); } public void Notify() { foreach(var obs in observers) { obs.Update(); } } public void Update() { observerState = subject.GetState(); }
  • 71.
    Observer – usecases • La modification d’un objet engendre des modifications dans d’autres objets qui sont déterminés dynamiquement • Un objet veut prévenir d’autres objets sans devoir connaitre leur type • pas de couplage <<abstract>> Subject + Add(Observer) + Remove(Observer) + Notify() ConcretSubject - subjectState + GetState() <<abstract>> Observer + Update() ConcreteObserver - observerState + Update() subject observer return subjectState; public void Add(Observer observer) { this.observers.Add(observer); } public void Notify() { foreach(var obs in observers) { obs.Update(); } } public void Update() { observerState = subject.GetState(); }
  • 72.
    Observer – Attention •Plusieurs implémentations • Garder le statut dans le sujet et l’appeler dans la méthode Update de l’observer • Ne pas exposer le statut du sujet et envoyer Event (contient les infos de notification) <<abstract>> Subject + Add(Observer) + Remove(Observer) + Notify(Event) <<abstract>> Observer + Update(Event) ConcreteObserver - observerState + Update(Event) observer public void Add(Observer observer) { this.observers.Add(observer); } public void Notify(Event e) { foreach(var obs in observers) { obs.Update(e); } } public void Update(Event e) { observerState = e; }
  • 73.
  • 74.
    Composer son PC •Choisir les options • Taille écran : 11’, 16’ … • Processeur : i5, i7 … • Mémoire RAM : 12 Go, 16 Go … • Taille du disque dur : 1To, SSD … • Carte vidéo : NVIDIA, AMD … • Casque : USB, Bluetooth … • Souris : filaire, sans fil… • Sac : à dos, sacoche … • Clavier : Azerty, Querty • Chaque option a un prix • Le prix du PC = prix de base (300€) + somme des options
  • 75.
  • 76.
    Chez le dentiste •L’assistante accueille les patients par ordre d’arrivée • Le dentiste ne sait pas s’il y a un patient qui attend, ni qui il est • Il demande de faire entrer le suivant • Il ne s’intéresse pas à la façon dont la salle d’attente est gérée. Dentist + EnterNext() Patient - name works with Secretary - patients : Collection<Patient> + HasNext() : bool + Next() : Patient
  • 77.
    Chez le dentiste •Introduire la notion de collection pour dissocier la collection en tant que tel et la manière de la parcourir • Si on change la règle d’itération par arrivée en itération par priorité Dentist + EnterNext() Patient - name works with Secretary + HasNext() : bool + Next() : Patient Patients +
  • 78.
    Chez le dentiste Dentist +EnterNext() Secretary + HasNext() : bool + Next() : Patient Patients + GetIterator() : IIterator <<Interface>> IIterable + GetIterator() : IIterator <<Interface>> IIterator + HasNext() : bool + Next() : IElement implements <<Interface>> IElement Name Patient Name instanciate IIterator GetIterator() { return new Secretary(); } void EnterNext() { IIterator iterator = this.patients.GetIterator(); if(iterator.HasNext()) { this.Receive(iterator.Next()); } }
  • 79.
    Iterator • Fournir unaccès séquentiel à une collection à des clients sans que ceux-ci doivent se préoccuper de l’implémentation de cette collection • Parcours séquentiel / variable • Enumération Client + DoSomething() ConcreteIterator<Element> + HasNext() : bool + Next() : Element ConcreteIterable + GetIterator() : IIterator<IElement> <<Interface>> IIterable + GetIterator() : IIterator<IElement> <<Interface>> IIterator<IElement> + HasNext() : bool + Next() : IElement implements <<Interface>> IElement Element instanciate void DoSomething() { IIterator<IElement> iterator = this.iterable.GetIterator(); if(iterator.HasNext()) { this.Receive(iterator.Next()); } }
  • 80.
    Iterator – usecases • Parcours du contenu d’une collection sans accéder à sa représentation interne • Gérer plusieurs parcours simultanément Client + DoSomething() ConcreteIterator<Element> + HasNext() : bool + Next() : Element ConcreteIterable + GetIterator() : IIterator<IElement> <<Interface>> IIterable + GetIterator() : IIterator<IElement> <<Interface>> IIterator<IElement> + HasNext() : bool + Next() : IElement implements <<Interface>> IElement Element instanciate void DoSomething() { IIterator<IElement> iterator = this.iterable.GetIterator(); if(iterator.HasNext()) { this.Receive(iterator.Next()); } }
  • 81.
    Iterator – Attention •L’ordre n’est pas maitrisé par le client mais plutôt par l’itérateur Client + DoSomething() ConcreteIterator<Element> + HasNext() : bool + Next() : Element ConcreteIterable + GetIterator() : IIterator<IElement> <<Interface>> IIterable + GetIterator() : IIterator<IElement> <<Interface>> IIterator<IElement> + HasNext() : bool + Next() : IElement implements <<Interface>> IElement Element instanciate void DoSomething() { IIterator<IElement> iterator = this.iterable.GetIterator(); if(iterator.HasNext()) { this.Receive(iterator.Next()); } }
  • 82.
  • 83.
    Catalogue de films •Au lieu de charger tout le film en mémoire, on affiche une image • Un clic sur la photo permet de jouer le film • But : réduire la quantité de mémoire utilisée
  • 84.
    Catalogue de films •Au lieu de charger tout le film en mémoire, on affiche une image • Un clic sur la photo permet de jouer le film • But : réduire la quantité de mémoire utilisée Animation + Show() + Clic() Film + Show() + Clic() + Run() AnimationSubstitute # photo + Show() + Clic() 0..1 #film public void Show() { if(film == null) photo.Show(); else film.Show(); } public void Clic() { if(film == null) { film = new Film(); } film.Run(); }
  • 85.
    Proxy • Concevoir unobjet qui se substitue à un autre et qui en contrôle l’accès <<Interface>> ISubject + DoSomething() RealSubject + DoSomething() Proxy - wrapee + DoSomething() Client public void DoSomething() { // Optionnal functionnality wrapee.DoSomething(); // Optionnal functionnality }
  • 86.
    Proxy – usecases • Proxy virtuel : créer un objet de taille importante au moment approprié • Proxy remote : accéder à un objet s’exécutant sur un autre environnement • Proxy de protection : sécuriser l’accès à un objet (authentification) <<Interface>> ISubject + DoSomething() RealSubject + DoSomething() Proxy - wrapee + DoSomething() Client public void DoSomething() { // Optionnal functionnality wrapee.DoSomething(); // Optionnal functionnality }
  • 87.
  • 88.
    Chez le grossistede fournitures bureau • Tous les mois, l’école passe la même commande de fournitures (stylo, feutres, papiers …) • Afin de faciliter la saisie pour ses clients, le grossiste a décidé de fournir une fonctionnalité de duplication de commande passée
  • 89.
    Chez le grossistede fournitures bureau • Fonctionnalité de duplication de commande <<Interface>> ICloneableOrder + Clone() Order + Clone() Client + CreateOrderFromAnother() order public void CreateOrderFromAnother() { ... var newOrder = order.Clone(); ... } public ICloneableOrder Clone() { return this.MemberwiseClone(); }
  • 90.
    Prototype • Créer denouveaux objets par duplication d’objets existants qui disposent de la capacité de clonage <<Interface>> IPrototype + Clone() ContretePrototype1 + Clone() ContretePrototype2 + Clone() Client + Operation() prototype public void Operation() { ... var clone = prototype.Clone(); ... } public IPrototype Clone() { return this.MemberwiseClone(); }
  • 91.
    Prototype – usescases • Créer des instances sans connaitre la hiérarchie des classes <<Interface>> IPrototype + Clone() ContretePrototype1 + Clone() ContretePrototype2 + Clone() Client + Operation() prototype public void Operation() { ... var clone = prototype.Clone(); ... } public IPrototype Clone() { return this.MemberwiseClone(); }
  • 92.
    Prototype – attention •Maitriser la duplication pour ne pas dégrader la performance
  • 93.
  • 94.
    Faire du shopping •Un client commande des articles sur internet • Statuts de la commande : • En cours : le client est en train de choisir les articles • Validée : le client valide et paye la commande • Livrée : le client reçoit les articles
  • 95.
    Memento • Sauvegarder etrestaurer l’état d’un objet sans en violer l’encapsulation Originator - state + SetMemento(Memento); + CreateMemento(); Memento - state + GetState() CareTaker public void SetMemento(Memento memento) { state = memento.GetState(); } public Memento CreateMemento() { return new Memento(state); }
  • 96.
    Memento – usecases • Quand l’état interne d’un objet (totalement ou partiellement) doit être mémorisé afin de pouvoir être restauré ultérieurement sans que l’encapsulation de cet objet ne doive être brisée Originator - state + SetMemento(Memento); + CreateMemento(); Memento - state + GetState() CareTaker public void SetMemento(Memento memento) { state = memento.GetState(); } public Memento CreateMemento() { return new Memento(state); }
  • 97.
  • 98.
    L’usine à chaussures •Ajouter un nouveau type : botte de pluie • Complexité combinatoire IShoe Sandal StreetShoe LeatherSandal SyntheticSandal LeatherStreetShoe SyntheticStreetShoe RainBoot LeatherRainBoot SyntheticRainBoot
  • 99.
    L’usine à chaussures •Eviter la complexité combinatoire <<Interface>> IShoe <<Interface>> IMaterial Sandal Shoe RainBoot Leather Synthetic
  • 100.
    Bridge • Séparer l’aspectd’implémentation d’un objet de son aspect de représentation et d’interface <<Interface>> IAbstraction + DoOperation() Client <<Interface>> IImplementor + DoOperationImplem() RefinedAbstraction ConcreteImplementorA + DoOperationImplem() ConcreteImplementorB + DoOperationImplem() DoOperation() { implementor.DoOperationImplem(); }
  • 101.
    Bridge – usecases • Eviter une liaison forte entre la représentation des objets et leur implémentation • Changer la représentation des objets sans impacter les interactions entre les objets et les clients • Garder la capacité d’extension par la création de nouvelles sous- classes • Eviter d’obtenir des hiérarchies de classes extrêmement complexes <<Interface>> IAbstraction + DoOperation() Client <<Interface>> IImplementor + DoOperationImplem() RefinedAbstraction ConcreteImplementorA + DoOperationImplem() ConcreteImplementorB + DoOperationImplem() DoOperation() { implementor.DoOperationImplem(); }
  • 102.
  • 103.
    Elements • Changement deWrite(), 3 fichiers touchés Folder + Name : String File + Name : String <<Interface>> IElement + Name : String <<Interface>> IReferenceableElement Link + Name : String References + Write() + Write() + Write() + Write()
  • 104.
    Elements Folder + Name :String File + Name : String <<Interface>> IElement + Name : String <<Interface>> IReferenceableElement Link + Name : String References + Accept(IWriter writer) + Accept(IWriter writer) + Accept(IWriter writer) + Accept(IWriter writer) Writer + Write(IElement element) + Write(Link link) + Writer(File file) + Write(Folder folder) <<Interface>> IWriter + Write(IElement element) + Write(Link link) + Writer(File file) + Write(Folder folder) public Write(IElement element) { element.Accept(this); } public Write(Link link) { Console.WriteLine(link.Name); } ... public Accept(IWriter writer) { writer.Write(this); }
  • 105.
    Visitor • Construire uneopération à réaliser sur les éléments d’un ensemble d’objets • De nouvelles opérations peuvent ainsi être ajoutées sans modifier les classes de ces objets <<Interface>> IElement + AcceptVisitor(IVisitor visitor) ConcreteElement1 + AcceptVisitor(IVisitor visitor) ConcreteElement2 + AcceptVisitor(IVisitor visitor) <<Interface>> IVisitor + Visit(ConcreteElement1 element) + Visit(ConcreteElement2 element) ConcreteVisitor1 + Visit(ConcreteElement1 element) + Visit(ConcreteElement2 element) ConcreteVisitor2 + Visit(ConcreteElement1 element) + Visit(ConcreteElement2 element) public AcceptVisitor(IVisitor visitor) { visitor.Visit(this); }
  • 106.
    Visitor – usecase • De nouvelles fonctionnalités doivent être ajoutées à un ensemble de classes sans que ces ajouts viennent alourdir ces classes • Un ensemble de classes possèdent une structure fixe et il est nécessaire de leur adjoindre des fonctionnalités sans modifier leur interface <<Interface>> IElement + AcceptVisitor(IVisitor visitor) ConcreteElement1 + AcceptVisitor(IVisitor visitor) ConcreteElement2 + AcceptVisitor(IVisitor visitor) <<Interface>> IVisitor + Visit(ConcreteElement1 element) + Visit(ConcreteElement2 element) ConcreteVisitor1 + Visit(ConcreteElement1 element) + Visit(ConcreteElement2 element) ConcreteVisitor2 + Visit(ConcreteElement1 element) + Visit(ConcreteElement2 element) public AcceptVisitor(IVisitor visitor) { visitor.Visit(this); }
  • 107.
    Visitor – attention •Complexité • Cycle de dépendance • Il faut avoir des getters dans les classes utilisées <<Interface>> IElement + AcceptVisitor(IVisitor visitor) ConcreteElement1 + AcceptVisitor(IVisitor visitor) ConcreteElement2 + AcceptVisitor(IVisitor visitor) <<Interface>> IVisitor + Visit(ConcreteElement1 element) + Visit(ConcreteElement2 element) ConcreteVisitor1 + Visit(ConcreteElement1 element) + Visit(ConcreteElement2 element) ConcreteVisitor2 + Visit(ConcreteElement1 element) + Visit(ConcreteElement2 element) public AcceptVisitor(IVisitor visitor) { visitor.Visit(this); }
  • 108.
  • 109.
    A la crêperie •Au menu, on trouve crêpe et gaufre. • On peut y ajouter du chocolat, des fraises, de la chantilly … • Le prix de la crêpe chocolat banane = prix crêpe + prix chocolat + prix banane
  • 110.
    A la crêperie •Au menu, crêpe et gaufre avec supplément chocolat, bananes, fraises, chantilly … Crepe + GetPrice() Waffle + GetPrice() <<Interface>> IDessert + GetPrice() Extra + GetPrice() Chocolate + GetPrice() Chantilly + GetPrice() Strawberry + GetPrice() dessert public GetPrice() { return this.price + this.dessert.GetPrice(); }
  • 111.
    Decorator • Ajouter dynamiquementdes fonctionnalités supplémentaires à un objet. <<Interface>> IComponent + DoSomething() ConcreteComponent + DoSomething() <<Interface>> IDecorator + DoSomething() Decorator + DoSomething() public Decorator(IComponent component) { this.component = component; } public DoSomething() { ... this.component.DoSomething-); ... }
  • 112.
    Decorator – usecase • Ajouter dynamiquement des fonctionnalités à un objet sans modifier son interface • Gérer des fonctionnalités qui peuvent être retirées dynamiquement • Eviter l’héritage complexe <<Interface>> IComponent + DoSomething() ConcreteComponent + DoSomething() <<Interface>> IDecorator + DoSomething() Decorator + DoSomething() public Decorator(IComponent component) { this.component = component; } public DoSomething() { ... this.component.DoSomething-); ... }
  • 113.
    Decorator – attention •Ce pattern ne traite pas l’ordre de composition ou de fabrication <<Interface>> IComponent + DoSomething() ConcreteComponent + DoSomething() <<Interface>> IDecorator + DoSomething() Decorator + DoSomething() public Decorator(IComponent component) { this.component = component; } public DoSomething() { ... this.component.DoSomething-); ... }
  • 114.
  • 115.
    Au roi duburger • Constituer son burger • Choisir le pain et ajouter des ingrédients avec type de portion • Légère • Normal • Extra
  • 116.
    Builder • Construire desobjets complexes sans préoccuper le client des différentes implémentations Director + Construct() <<Interface>> IBuilder + BuildFirstPart() + BuildSecondPart() + GetProduct() ConcreteBuilder + BuildFirstPart() + BuildSecondPart() + GetProduct() Product
  • 117.
    Builder – usecase • Le client a besoin de construire un objet complexe sans connaitre son implémentation • Le client a besoin de construire des objets complexes ayant plusieurs implémentations ou représentations Director + Construct() <<Interface>> IBuilder + BuildFirstPart() + BuildSecondPart() + GetProduct() ConcreteBuilder + BuildFirstPart() + BuildSecondPart() + GetProduct() Product
  • 118.
    Builder – attention •Quand il s’agit d’une construction step by step • Complexité du code Director + Construct() <<Interface>> IBuilder + BuildFirstPart() + BuildSecondPart() + GetProduct() ConcreteBuilder + BuildFirstPart() + BuildSecondPart() + GetProduct() Product
  • 119.
  • 120.
    Un peu demathématiques • Réalisez l’expression suivante (4 - 5) * 2 • L’idée est de pouvoir réaliser plusieurs opérations à la suite ((4 - 5) * 2) + (4 * (1 + 6)) 4 5 -1 - 2 -2 * 1 6 4 + 7 28 * + 26
  • 121.
    Un peu demathématiques Operand + Evaluate() Operator + Evaluate() <<Interface>> IExpression + Evaluate() PlusOperator + Evaluate() MinusOperator + Evaluate() 2 #LeftExpression #RightExpression public Operand(double value) { this.operand = value; } public double Evaluate() { return this.operand; } public double Evaluate() { return this.leftExpression.Evaluate() + this.rightExpression.Evaluate(); } public Operator(IExpression leftExpression, IExpression rightExpression) { this.leftExpression = leftExpression; this.rightExpression = rightExpression; } public abstract double Evaluate(); public double Evaluate() { return this.leftExpression.Evaluate() - this.rightExpression.Evaluate(); }
  • 122.
    Interpreter • Définir unereprésentation de grammaire pour interpréter des expressions TerminalExpression + Interpret(Context) NonTerminalExpression + Interpret(Context) <<Interface>> IExpression + Interpret(Context) NonTerminalExpression1 + Interpret(Context) NonTerminalExpression2 + Interpret(Context)
  • 123.
    Interpreter – usecases • Interpréter des expressions représentées sous forme d’arbres syntaxiques • Quand la grammaire des expressions est simple • L’évaluation n’a pas besoin d’être rapide • Si la grammaire est complexe, il vaut mieux utiliser un analyseur syntaxique • Si l’évaluation doit être rapide, il vaut mieux utiliser un compilateur TerminalExpression + Interpret(Context) NonTerminalExpression + Interpret(Context) <<Interface>> IExpression + Interpret(Context) NonTerminalExpression1 + Interpret(Context) NonTerminalExpression2 + Interpret(Context)
  • 124.
  • 125.
  • 126.
    Comportement graphique dessites web • La modification d’une valeur d’un widget peut conduire à modifier l’aspect d’autres widget : • Visible ou masqué • Changement des valeurs d’un menu • Changement du format des valeurs • Inconvénient • Chaque objet doit connaitre tous les objets dépendants • La réutilisabilité des objets est réduite Widget 1 Widget 2 Widget 3 Widget 4 Widget 5 Widget 6
  • 127.
    Mediator • Construire unobjet dont la vocation est la gestion et le contrôle des interactions dans un ensemble d’objets sans que ses éléments doivent se connaitre mutuellement. <<Interface>> Mediator + DoSomething() <<Interface>> Element ConcreteElement1 ConcreteElement1 ConcreteMediator
  • 128.
    Mediator – usecases • Un système est formé d’un ensemble d’objets basé sur une communication complexe conduisant à associer de nombreux objets entre eux • Les objets d’un système sont difficiles à réutiliser car ils possèdent de nombreuses associations avec d’autres objets • La modularité d’un système est médiocre, obligeant dans le cas d’une adaptation d’une partie du système à écrire de nombreuses sous classes. <<Interface>> Mediator + DoSomething() <<Interface>> Element ConcreteElement1 ConcreteElement1 ConcreteMediator
  • 129.
  • 130.
    Distributeur de billets Source: https://sourcemaking.com/design_patterns/chain_of_responsibility
  • 131.
    Chain of responsibility •Une chaine d’objets tel que si un objet ne peut pas répondre à une requête, il puisse la transmettre à son successeur jusqu’à ce que l’un des objets de la chaine y réponde. Handler + HandleRequest() successor ConcreteHandler1 + HandleRequest() ConcreteHandler1 + HandleRequest() Client
  • 132.
    Chain of responsibility– use cases • Une chaine d’objets gère une requête selon un ordre qui es défini dynamiquement • La façon dont une chaine d’objets gère une requête ne doit pas être connue par le client Handler + HandleRequest() successor ConcreteHandler1 + HandleRequest() ConcreteHandler1 + HandleRequest() Client
  • 133.
  • 134.
    Composer son PC •Choisir les options • Taille écran : 11’, 16’ … • Processeur : i5, i7 … • Mémoire RAM : 12 Go, 16 Go … • Taille du disque dur : 1To, SSD … • Carte vidéo : NVIDIA, AMD … • Casque : USB, Bluetooth … • Souris : filaire, sans fil… • Sac : à dos, sacoche … • Clavier : Azerty, Querty • Chaque option a un prix • Le prix du PC = prix de base (300€) + somme des options
  • 135.
    Flyweight • Permet departager de façon efficace un ensemble important d’objets de granularité fine FlyweightFabric + GetFlyweight(key) Flyweight - intrinsicState + Operation(extrinsicState) Client if(flyweights.ContainsKey(key)) { return flyweights[key]; } else { var newFlyweight = new Flyweight(); flyweights.Add(key, newFlyweight); return newFlyweight; }
  • 136.
    Flyweight – usecases • Le système utilise un grand nombre d’objets • Le stockage des objets est couteux à cause d’une grande quantité • Il existe de nombreux ensembles d’objets qui peuvent être remplacés par quelques objets partagés une fois qu’une partie de leur état est rendue extrinsèque FlyweightFabric + GetFlyweight(key) Flyweight - intrinsicState + Operation(extrinsicState) Client if(flyweights.ContainsKey(key)) { return flyweights[key]; } else { var newFlyweight = new Flyweight(); flyweights.Add(key, newFlyweight); return newFlyweight; }
  • 137.
  • 138.
    Chez le concessionnaire •Un client veut passer une commande pour une voiture • Il a le choix de payer au comptant ou à crédit
  • 139.
    Chez le concessionnaire •Un client veut passer une commande pour une voiture • Il a le choix de payer au comptant ou à crédit OrderCreator + CreateNewOrder() - CreateOrder() : Order Order + Pay(); + IsValid() : bool SpotOrder + Pay(); + IsValid() : bool ForwardOrder + Pay(); + IsValid() : bool public void CreateNewOrder() { Order order= CreateOrder(); if(order.IsValid()) { order.Pay(); } } private Order CreateOrder() { if(paymentType == PaymentType.Spot) { return new SpotOrder(); } else { return new ForwardOrder(); } }
  • 140.
    Chez le concessionnaire BaseOrderCreator +CreateNewOrder() # CreateOrder() : Order SpotOrderCreator # CreateOrder() : Order Order + Pay(); + IsValid() : bool SpotOrder + Pay(); + IsValid() : bool ForwardOrder + Pay(); + IsValid() : bool ForwardOrderCreator # CreateOrder() : Order public void CreateNewOrder() { Order order= CreateOrder(); if(order.IsValid()) { order.Pay(); } } protected Order CreateOrder() { return new SpotOrder(); } protected Order CreateOrder() { return new ForwardOrder(); }
  • 141.
    AbstractCreator + CreateProduct() :IProduct Creator + CreateProduct() : IProduct IProduct Product Factory Method • Introduire une méthode abstraite de création d’un objet en reportant aux sous-classes concrètes la création effective
  • 142.
    AbstractCreator + CreateProduct() :IProduct Creator + CreateProduct() : IProduct IProduct Product Factory Method – use cases • Une classe ne connait que les classes abstraites des objets avec lesquels elle possède des relations • Une classe veut transmettre à ses sous-classes les choix d’instanciation en profitant du mécanisme de polymorphisme
  • 143.
  • 144.
    Période des soldes •Le responsable du magasin a besoin d’appliquer et annuler une réduction sur un produit • Aujourd’hui -20% sur le prix initial • Demain -10% supplémentaires => -30% en tout • Le lendemain annuler le -10% => -20% en tout
  • 145.
    Command • Permet detransformer une requête en un objet pour faciliter les opérations comme l’annulation ou la mise en file des requêtes et leur suivi Command + Execute() <<Interface>> ICommand + Execute() Invoker + SetCommand(ICommand) + ExecuteCommand() IReceiver + Action() receiver.Action();
  • 146.
    Command – usecases • Un objet doit être paramétré par un traitement à réaliser • Les commandes • À stocker dans une file • À exécuter à tout moment ou plusieurs fois • À Annuler • À tracer dans un fichier de log Command + Execute() <<Interface>> ICommand + Execute() Invoker + SetCommand(ICommand) + ExecuteCommand() IReceiver + Action() receiver.Action();
  • 147.
    Command – attention •Les commandes peuvent être regroupées sous la forme d’une transaction (un ensemble ordonné de commandes qui agissent sur l’état d’un système, si l’une est annulée tout l’ensemble l’est aussi) Command + Execute() <<Interface>> ICommand + Execute() Invoker + SetCommand(ICommand) + ExecuteCommand() IReceiver + Action() receiver.Action();