152114013: Object Oriented Programming II

Introduction
to Design
Patterns
Instructor: Dr. Metin zkan

M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

GoF Classification Of Design Patterns

Purpose - what a pattern does

 Creational Patterns
o Concern the process of object creation

 Structural Patterns
o Deal with the composition of classes and objects

 Behavioral Patterns
o Deal with the interaction of classes and objects

Scope - what the pattern applies to

 Class Patterns
o Focus on the relationships between classes and their subclasses
o Involve inheritance reuse

 Object Patterns
o Focus on the relationships between objects
o Involve composition reuse
M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

GoF Classification Of Design Patterns

M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

GoF Essential Elements Of Design Patterns

Pattern Name
 Having a concise, meaningful name for a pattern improves communication
among developers

Problem
 What is the problem and context where we would use this pattern?
 What are the conditions that must be met before this pattern should be used?

Solution
 A description of the elements that make up the design pattern
 Emphasizes their relationships, responsibilities and collaborations
 Not a concrete design or implementation; rather an abstract description

Consequences
 The pros and cons of using the pattern
 Includes impacts on reusability, portability, extensibility
M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

GoF Pattern Template

Pattern Name and Classification

 A good , concise name for the pattern and the pattern's type

Intent
 Short statement about what the pattern does

Also Known As
 Other names for the pattern

Motivation
 A scenario that illustrates where the pattern would be useful

Applicability
 Situations where the pattern can be used

M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

GoF Pattern Template (Continued)

Structure
 A graphical representation of the pattern

Participants
 The classes and objects participating in the pattern

Collaborations
 How to do the participants interact to carry out their responsibilities?

Consequences
 What are the pros and cons of using the pattern?

Implementation
 Hints and techniques for implementing the pattern

M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

GoF Pattern Template (Continued)

Sample Code
 Code fragments for a sample implementation

Known Uses
 Examples of the pattern in real systems

Related Patterns
 Other patterns that are closely related to the pattern

M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

Welcome to Design Patterns

Let us start with a simple SimUDuck application

Problem: A company makes a highly successful duck pond simulation

game, SimUDuck.

The game can show a large variety of duck species swimming and
making quaking sounds.

The initial designers of the system used standard OO techniques and
created one Duck superclass from which all other duck types inherit.

M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

But now we need the ducks to FLY

Problem: The executives decided that flying ducks is just what the
simulator needs to blow away the other duck sim competitors.

Solution: Just add a fly() method in the Duck class and all the ducks
will inherit it.

M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

But something went horribly wrong

Problem: The executives failed to notice that not all subclasses of

Duck should fly.

M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

But something went horribly wrong

Solution: Just override the fly() method in rubber duck.

Problem: what happens when we add wooden decoy ducks to the
program? They arent supposed to be fly or quack

Solution: also override them.

M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

How about an interface

Problem: Inheritance probably wasnt the solution, because the

executives now want to update the product every six months.
 The spec will keep changing and possibly override fly() and quack() for
every new Duck subclass thats ever added to the program forever.

Solution: make Flyable() interface with a fly() method. Only the ducks
that are supposed to fly will implement that interface and have a fly()
method

M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

How about an interface

Problem: The Flyable and Quackable interface sounded promising at

first.
 But, interfaces have no implementation code except Java, so no code
reuse.
 Also whenever you need to modify a behavior, youre forced to track
down and change it in all the different subclasses where that behavior is
defined. (probably introducing bugs )

Solution: take the parts that vary and encapsulate them, so that later
you can alter or extend the parts that vary without affecting those that
dont. (This concept forms the basis for almost every design pattern.)

M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

Separating what changes from what stays the same

Fly() and quack() are the parts of the Duck class that vary across
ducks.

To separate these behaviors from the Duck class, pull both methods
out of the Duck class and create a new set of classes to represent each
behavior.

Put out what varies

Duck
class

Flying
Behaviors

Quacking
Behaviors

Duck Behaviors
M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

Designing the Duck Behaviors

The Duck behaviors will live in a separate class a class that
implements a particular behavior interface.

That way, the Duck classes wont need to know any of the
implementation details for their behaviors.

We want to assign behaviors to the instances of Duck. For example,
we might want to instantiate a new MallardDuck instance and initialize
it with a specific type of flying behavior.

We can change the behavior of a Duck dynamically. In other words,
we should include behavior setter methods in the Duck classes so that
we can change the MallardDucks flying behavior at runtime.

Given these goals, lets look at the second design principle:

o Program to an interface, not an implementation.

M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

Implementing the Duck Behaviors

With this design, other types of objects can reuse our fly and quack
behaviors because these behaviors are no longer hidden away in our
Duck classes.

New behavior can be added without modifying any existing behavior
classes or touching any Duck classes.

M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

Integrating the Duck Behavior

The key is that a Duck will now delegate its flying and quacking
behavior, instead of using quacking and flying methods defined in the
Duck class (or subclass).

1) First well add two instance variables to the Duck class.

o flyBehavior and quackBehavior

 Replace the fly() and quack() methods with

o performFly() and performQuack()

Instance variable hold a reference

to a specific behavior at runtime.

Flying
Behaviors

Quacking
Behaviors

Duck Behaviors

M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

Integrating the Duck Behavior

2) Now we implement performQuack:

class Duck{
private:
QuackBehavior *quackBehavior;
// more
public:
void performQuack(){quackBehavior->quack();}
};

M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

Integrating the Duck Behavior

3 ) Okay, how the flyBehavior and quackBehavior instance

variables are set. Lets take a look at the MallardDuck class:
class MallardDuck:public Duck{
public:
MallardDuck(){
quackBehavior=new Quack();
flyBehavior=new FlyWithWings();
}
void display(){
cout<<"I'm a real Mallard duck"<<endl;
}
};

M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

Testing the Duck code

1 ) Type and compile the Duck class below(Duck.h) and the

MallardDuck class given before (MallardDuck.h):
class Duck{
protected:
QuackBehavior *quackBehavior;
FlyBehavior *flyBehavior;
public:
Duck(){}
virtual ~Duck() = 0;
virtual void display()=0;
void performQuack(){quackBehavior->quack();}
void performFly(){flyBehavior->fly();}
void swim(){
cout<<"All ducks float, even decoys!"<<endl;
}
};

M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

Testing the Duck code

2 ) Type and compile the FlyBehavior interface (FlyBehaviour.h) and

the two behaviors (FlyWithWings.h and FlyNoWay.h):
class FlyBehavior{
public:
virtual void fly()=0;
};
class FlyWithWings:public FlyBehavior{
public:
void fly(){
cout<<"I'm flying!!"<<endl;
}
};
class FlyNoWay:public FlyBehavior{
public:
void fly(){
cout<<"I can't fly"<<endl;
}
};
M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

Testing the Duck code

3) Type and compile the QuackBehavior interface (QuackBehaviour.h)

and the three behaviors (Quack.h, MuteQuack.h and Squeak.h):
class QuackBehavior{
public:
virtual void quack()=0;
};
class Quack:public QuackBehavior{
public:
void quack(){
cout<<"Quack"<<endl;
}
};
class MuteQuack:public QuackBehavior{
public:
void quack(){
cout<<"<< silence >>"<<endl;
}
};
class Squeak:public QuackBehavior{
public:
void quack(){
cout<<"Squeak"<<endl;
}
};
M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

Testing the Duck code

4) Type and compile the test program (MiniDuckSimulator.cpp):

int main(){
Duck *mallard=new MallardDuck();
mallard->performQuack();
mallard->performFly();
return 0;
}

M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

Setting behavior dynamically

1)Add two new methods to the Duck class:

 Call these methods anytime to change the behavior of a Duck on the fly.
void setFlyBehavior(FlyBehavior *fb){
flyBehavior=fb;
}
void setQuackBehavior(QuackBehavior *qb){
quackBehavior=qb;
}

M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

Setting behavior dynamically

2)Make a new Duck type (ModelDuck.h):

 Call these methods anytime to change the behavior of a Duck on the fly.
class ModelDuck:public Duck{
public:
ModelDuck(){
quackBehavior=new Quack();
flyBehavior=new FlyNoWay();
}
void display(){
cout<<"I'm a model duck"<<endl;
}
};

M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

Setting behavior dynamically

3)Make a new FlyBehavior type (FlyRocketPowered.h)

class FlyRocketPowered:public FlyBehavior{
public:
void fly(){
cout<<"I'm flying with a rocket!"<<endl;
}
};

M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

Setting behavior dynamically

4)Change the test class (MiniDuckSimulator.cpp), add the

ModelDuck, and make the ModelDuck rocket-enabled.
int main(){
Duck *mallard=new MallardDuck();
mallard->performQuack();
mallard->performFly();
Duck *model=new ModelDuck();
model->performFly();
model->setFlyBehavior(new FlyRocketPowered());
model->performFly();
return 0;
}

M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

The Big Picture on encapsulated behaviors

Think of each set of

behaviors as a
family of algorithms

Encapsulated fly behavior

Client makes use of an encapsulated family of algorithms
for both flying and quacking

Client

Encapsulated quack behavior

These behaviors
algorithms are
interchangeable.
M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

Speaking of Design Patterns

Here, we applied a desig pattern called as

STRATEGY pattern
The Strategy Pattern defines a family of algorithms, encapsulates
each one, and makes them interchangeable. Strategy lets the algorithm
vary independently from clients that use it.

M. Ozkan, 02.2012, Ver. 1.0

152114013: Object Oriented Programming II

References
 Design Patterns: Elements of Reusable Object-Oriented Software,
Gamma, Helm, Johnson and Vlissides, Addison-Wesley, 1995
 Head First Design Patterns, Freeman and Freeman, O'Reilly, 2004

M. Ozkan, 02.2012, Ver. 1.0