CS 210

Introduction to Design Patterns

August 29, 2006

Head First: Design Patterns

Eric Freeman & Elisabeth Freeman

O’Reilly Press, 2004

Introduction to Design Patterns

Chapter 1

Strategy Pattern

Goals for this week

Learn how to exploit and gain experience of others

Examine the benefits of design pattern Learn one specific pattern: Strategy

pattern

Simple Simulation of Duck behavior

Duck

quack()swim()display()// other duck methods

MallardDuck

display()// looks like mallard

RedheadDuck

display()// looks like redhead

Other ducktypes

What if we want to simulate flying ducks?

Duck

quack()swim()display()fly()// other duck methods

MallardDuck

display()// looks like mallard

RedheadDuck

display()// looks like redhead

Other ducktypes

Tradeoffs in use of inheritance and maintenance

Duck

quack()swim()display()fly()// other duck methods

MallardDuck

display()// looks like mallard

RubberDuck

quack()//overridden to squeakdisplay()// looks like rubberduckfly()// override to do nothing

RedheadDuck

display()// looks like redhead

One could override thefly method to the appropriatething – just as the quackmethod below.

Example complicated: add a wooden decoy ducks to the mix

DecoyDuck

quack(){// override to do nothing}display()// display decoy duckfly (){//override to do nothing}

Inheritance is not always the rightanswer. Every new class that inheritsunwanted behavior needs to beoverridden.

How about using interfaces instead?

Duck simulation recast using interfaces.

Duck

swim()display()// other duck methods

MallardDuck

display()fly()quack()

Quackable

quack()

Flyable

fly()

RedheadDuck

display()fly()quack()

RubberDuck

display()quack()

DecoyDuck

display()

Interfaces

Pros and cons Not all inherited methods make sense for all

subclasses – hence inheritance is not the right answer

But by defining interfaces, every class that needs to support that interface needs to implement that functionality… destroys code reuse!

So if you want to change the behavior defined by interfaces, every class that implements that behavior may potentially be impacted

And….

Design Principle

Identify the aspects of your application that vary and separate them from what stays the same.

ORTake the parts that vary and encapsulate

them, so that later you can alter or extend the parts that vary without affecting those that don’t.

In the Duck simulation context…

DuckBehaviors

Parts that varyParts that stay the same

Design Principle

Program to an interface, not to an implementation.

Really means program to a super type.

Program to an interface

Programming to an implementationDog d = new Dog();

d.bark();

Programming to an interfaceAnimal animal = new Dog();

animal.makesound();

Implementing duck behaviors - revisited

FlyWithWings

fly(){// implements duckflying}

<<interface>>FlyBehavior

fly()

<<interface>>QuackBehavior

quack()

Quack

quack(){// implements duckquacking}

FlyNoWay

fly(){// do nothing – Can’t fly}

Squeak

quack(){// implements ducksqueak}

MuteQuack

quack(){// do nothing –Can’t quack}

Integrating the duck behavior

Key now is that Duck class will delegate its flying and quacking behavior instead of implementing these itself.

In the Duck simulation context…

DuckBehaviors

Duck

FlyBehavior: flyBehaviorQuackBehavior: quackBehavior

performQuack()swim()display()performFly()//other duck-like methods

Duck simulation recast using the new approach

MallardDuck

display()

RedHeadDuck

display()

RubberDuck

display()

DecoyDuck

display()

Duck

FlyBehavior: flyBehaviorQuackBehavior: quackBehavior

performQuack()performFly()setFlyBehavior()setQuackBehavior()swim()display()

<<interface>>FlyBehavior

fly()

FlyWithWings

fly()// implements duckflying

FlyNoWay

fly()// do nothing –Can’t fly

<<interface>>QuackBehaviorquack()

Quackquack()// implements duckquacking

Squeakquack()// implements squeak

Mutequackquack()// do nothing

Design Principle

Favor composition over inheritance

HAS-A can be better than IS-A Allows changing behavior at run time

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

Rationale for design patterns

Shared pattern vocabularies are powerful

Patterns allow you to say more with less Reusing tried and tested methods Focus is on developing flexible,

maintainable programs