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
Duck quack() swim() display() // other duck methods Simple Simulation of Duck behavior RedheadDuck MallardDuck Other duck types display() // looks like redhead display() // looks like mallard
Duck quack() swim() display() fly() // other duck methods What if we want to simulate flying ducks? RedheadDuck MallardDuck Other duck types display() // looks like redhead display() // looks like mallard
Duck quack() swim() display() fly() // other duck methods RubberDuck RedheadDuck MallardDuck quack() //overridden to squeak display() // looks like rubberduck fly() // override to do nothing display() // looks like redhead display() // looks like mallard Tradeoffs in use of inheritance and maintenance One could override the fly method to the appropriate thing – just as the quack method below.
DecoyDuck quack(){ // override to do nothing } display() // display decoy duck fly (){ //override to do nothing } Example complicated: add a wooden decoy ducks to the mix Inheritance is not always the right answer. Every new class that inherits unwanted behavior needs to be overridden. How about using interfaces instead?
Quackable Flyable Duck quack() fly() swim() display() // other duck methods RubberDuck DecoyDuck display() quack() display() MallardDuck RedheadDuck display() fly() quack() display() fly() quack() Duck simulation recast using interfaces. 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….
Change is Constant In software development
Design Principle Identify the aspects of your application that vary and separate them from what stays the same. OR Take 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… Parts that vary Parts that stay the same Duck Behaviors Flying Behaviors Duck Class Quacking Behaviors
Design Principle • Program to an interface, not to an implementation. • Really means program to a super type.
Program to an interface • Programming to an implementation Dog d = new Dog(); d.bark(); • Programming to an interface Animal animal = new Dog(); animal.makesound();
<<interface>> FlyBehavior <<interface>> QuackBehavior fly() quack() FlyWithWings Quack FlyNoWay Squeak MuteQuack fly(){ // implements duck flying } quack(){ // implements duck quacking } fly(){ // do nothing – Can’t fly } quack(){ // implements duck squeak } quack(){ // do nothing – Can’t quack } Implementing duck behaviors - revisited
Integrating the duck behavior • Key now is that Duck class will delegate its flying and quacking behavior instead of implementing these itself.
Duck FlyBehavior: flyBehavior QuackBehavior: quackBehavior performQuack() swim() display() performFly() //other duck-like methods In the Duck simulation context… Duck Behaviors Flying Behaviors Quacking Behaviors
<<interface>> FlyBehavior Duck fly() FlyBehavior: flyBehavior QuackBehavior: quackBehavior performQuack() performFly() setFlyBehavior() setQuackBehavior() swim() display() FlyWithWings FlyNoWay fly() // implements duck flying fly() // do nothing – Can’t fly <<interface>> QuackBehavior quack() DecoyDuck MallardDuck RubberDuck Quack Squeak quack() // implements squeak quack() // implements duck quacking RedHeadDuck display() display() display() display() Mutequack quack() // do nothing Duck simulation recast using the new approach
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
