ECE 355 Design Patterns Tutorial Part 2 based
ECE 355 Design Patterns Tutorial Part 2 (based on slides by Ali Razavi) Presented by Igor Ivković iivkovic@swen. uwaterloo. ca
Agenda Ø Design Patterns Ø Abstract Factory o Singleton o Façade o Observer o Strategy o Summary and References 2
Abstract Factory /1 § Intent: – Provide an interface for creating families of related or dependent objects without specifying their concrete classes § Applicability: – A system should be independent of how its products are created, composed and represented – A system should be configured with one of multiple families of products – A family of related product objects is designed to be together and this constraint needs to be enforced – A class library of products is to be developed so that only their interfaces and not their implementations are revealed 3
Abstract Factory /2 4
Abstract Factory /3 5
Abstract Factory /4 6
Abstract Factory /5 7
Abstract Factory /6 8
Agenda Ø Design Patterns ü Abstract Factory Ø Singleton o Façade o Observer o Strategy o Summary and References 9
Singleton /1 § Intent: – Ensure that a class only has one instance, and provide a global point of access to it § Applicability: – There must be exactly one instance of a class, and it must be accessible to clients from a well-known access point – When the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code 10
Singleton /2 11
Agenda Ø Design Patterns ü Abstract Factory ü Singleton Ø Façade o Observer o Strategy o Summary and References 12
Façade /1 § Intent: – Provide a unified interface to a set of interfaces in a subsystem – Facade defines a higher-level interface that makes the subsystem easier to use § Applicability: – A simple interface for complex subsystems – There are many dependencies between clients and the implementation classes of an abstraction – You want to layer your subsystems 13
Façade /2 14
Façade /3 15
Façade /4 16
Agenda Ø Design Patterns ü Abstract Factory ü Singleton ü Façade Ø Observer o Strategy Ø Summary and References 17
Observer /1 § In a system partitioned into classes, consistency between related objects must be maintained – To maintain their reusability, classes must not be tightly coupled § The observer pattern addresses dependency between objects without increasing the coupling between classes § Is useful when data must be presented in several different forms at one time – The objects that display the data are separate from the one that contains the data – The display objects observe changes in that data http: //sern. ucalgary. ca/courses/seng/443/f 2004/pattern. Notes/Hanna_Tseng_&_Xing/ 18
Observer /2 § Definition: “Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically” § Also known as: Publish-Subscribe, Dependents § This pattern can be used in any of the following situations: – A change in one object requires changing other objects, and the number of objects to be changed is not known – The objects not be tightly coupled, i. e. no assumptions should be made about the type of the objects being notified – Encapsulating dependent aspects of an abstraction in separate objects allows them to be reused independently Design Patterns - Gamma, et al, 1995 19
Observer /3 20
Observer /4 § In the example on previous slide: – The Observer design pattern’s key objects are the subject and observer – The subject is in a one-to-many relationship with the observer – All observers are intimated when there is any type of state change in the subject – Observers use the state of the subject to synchronize their own state http: //sern. ucalgary. ca/courses/seng/443/f 2004/pattern. Notes/Hanna_Tseng_&_Xing/ 21
Observer /5 § Observer Pattern Structure is as follows: 22
Agenda Ø Design Patterns ü Abstract Factory ü Singleton ü Façade ü Observer Ø Strategy Ø Summary and References 23
Strategy /1 § Definition: “Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it” § Also known as: Policy Design Patterns - Gamma, et al, 1995 24
Strategy /2 § This pattern can be used in any of the following situations: – The only difference in related classes is their behavior – Different variants [class hierarchy] of an algorithm are needed – Clients should not know about the data being used by an algorithm – Instead of multiple conditional statements when a class defines many behaviors http: //www. cs. clemson. edu/~malloy/courses/patterns/strategy. html 25
Strategy /3 § The structure of the Strategy pattern is as follows 26
Agenda ü Design Patterns ü Abstract Factory ü Singleton ü Façade ü Observer ü Strategy Ø Summary and References 27
Tutorial Summary § In this tutorial, we have presented the following design patterns: – Abstract Factory, Singleton, Façade, Observer, and Strategy § We have demonstrated intent, applicability conditions, and illustrative examples for each pattern § We have also discussed pointers for further study 28
References § E. Gamma, R. Helm, R. Johnson, H. Vlissides, Design Patterns, Addison-Wesley, 1994. § B. Bruegge and A. H. Dutoit, Object-Oriented Software Engineering, Prentice Hall, 2004. 29
- Slides: 29