ECE 355 Design Patterns Tutorial ECE 355 Design Patterns Tutorial Part 2Part 2

(based on slides by Ali Razavi)(based on slides by Ali Razavi)

Presented by Igor Ivkovićiivkovic@swen.uwaterloo.ca

2

AgendaAgenda

Design Patterns

Abstract Factory

o Singleton

o Façade

o Observer

o Strategy

o Summary and References

3

Abstract Factory /1Abstract 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 /2Abstract Factory /2

5

Abstract Factory /3Abstract Factory /3

6

Abstract Factory /4Abstract Factory /4

7

Abstract Factory /5Abstract Factory /5

8

Abstract Factory /6Abstract Factory /6

9

AgendaAgenda

Design Patterns

Abstract Factory

Singleton

o Façade

o Observer

o Strategy

o Summary and References

10

Singleton /1Singleton /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 /2Singleton /2

12

AgendaAgenda

Design Patterns

Abstract Factory

Singleton

Façade

o Observer

o Strategy

o Summary and References

13

FaFaççade /1ade /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

FaFaççade /2ade /2

15

FaFaççade /3ade /3

16

FaFaççade /4ade /4

17

AgendaAgenda

Design Patterns

Abstract Factory

Singleton

Façade

Observer

o Strategy

Summary and References

18

Observer /1Observer /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 /2Observer /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 /3Observer /3

21

Observer /4Observer /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 /5Observer /5

Observer Pattern Structure is as follows:

23

AgendaAgenda

Design Patterns

Abstract Factory

Singleton

Façade

Observer

Strategy

Summary and References

24

Strategy /1Strategy /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 /2Strategy /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 /3Strategy /3

The structure of the Strategy pattern is as follows

27

AgendaAgenda

Design Patterns

Abstract Factory

Singleton

Façade

Observer

Strategy

Summary and References

28

Tutorial SummaryTutorial 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

ReferencesReferences

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.