1. 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ć

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

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

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

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.