Presented by Igor Ivković iivkovic@swen.uwaterloo.ca 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 Singleton Façade Observer Strategy Summary and References

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

Abstract Factory /2

Abstract Factory /3

Abstract Factory /4

Abstract Factory /5

Abstract Factory /6

Agenda Design Patterns Abstract Factory Singleton Façade Observer Strategy Summary and References

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

Singleton /2

Agenda Design Patterns Abstract Factory Singleton Façade Observer Strategy Summary and References

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

Façade /2

Façade /3

Façade /4

Agenda Design Patterns Abstract Factory Singleton Façade Observer Strategy Summary and References

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/f2004/patternNotes/Hanna_Tseng_&_Xing/

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

Observer /3

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/f2004/patternNotes/Hanna_Tseng_&_Xing/

Observer /5 Observer Pattern Structure is as follows:

Agenda Design Patterns Abstract Factory Singleton Façade Observer Strategy Summary and References

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

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

Strategy /3 The structure of the Strategy pattern is as follows

Agenda Design Patterns Abstract Factory Singleton Façade Observer Strategy Summary and References

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

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.