CS 210 Introduction to Design Patterns August 29, 2006.
-
Upload
sandra-griffin -
Category
Documents
-
view
216 -
download
0
Transcript of CS 210 Introduction to Design Patterns August 29, 2006.
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