ECE 355 Design Patterns Tutorial Part 2 (based on slides by Ali Razavi) Presented by Igor Ivković

2 Agenda  Design Patterns  Abstract Factory oSingleton oFaçade oObserver oStrategy oSummary 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 oFaçade oObserver oStrategy oSummary 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 oObserver oStrategy oSummary 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 oStrategy  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,  B. Bruegge and A. H. Dutoit, Object-Oriented Software Engineering, Prentice Hall, 2004.