ECE 355 Design Patterns Tutorial Part 2 (based on slides by Ali Razavi)

1. ECE 355 Design Patterns Tutorial Part 2(based on slides by Ali Razavi) Presented by Igor Ivkovićiivkovic@swen.uwaterloo.ca

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

3. 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

4. Abstract Factory /2

5. Abstract Factory /3

6. Abstract Factory /4

7. Abstract Factory /5

8. Abstract Factory /6

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

10. 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

11. Singleton /2

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

13. 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

14. Façade /2

15. Façade /3

16. Façade /4

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

18. 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/

19. 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

20. Observer /3

21. 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/

22. Observer /5 • Observer Pattern Structure is as follows:

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

24. 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

25. 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

26. Strategy /3 • The structure of the Strategy pattern is as follows

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

28. 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

29. 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.