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 duck types

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 duck types

Tradeoffs in use of inheritance and maintenance Duck quack() swim() display() fly() // other duck methods MallardDuck display() // looks like mallard RubberDuck quack() //overridden to squeak display() // looks like rubberduck fly() // override to do nothing RedheadDuck display() // looks like redhead One could override the fly method to the appropriate thing – just as the quack method below.

Example complicated: add a wooden decoy ducks to the mix DecoyDuck quack(){ // override to do nothing } display() // display decoy duck fly (){ //override to do nothing } Inheritance is not always the right answer. Every new class that inherits unwanted behavior needs to be overridden. 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. 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… Duck Behaviors Parts that vary Parts 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 implementation Dog d = new Dog(); d.bark(); Programming to an interface Animal animal = new Dog(); animal.makesound();

Implementing duck behaviors - revisited FlyWithWings fly(){ // implements duck flying } > FlyBehavior fly() > QuackBehavior quack() Quack quack(){ // implements duck quacking } FlyNoWay fly(){ // do nothing – Can’t fly } Squeak quack(){ // implements duck squeak } 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… Duck Behaviors Duck FlyBehavior: flyBehavior QuackBehavior: 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: flyBehavior QuackBehavior: quackBehavior performQuack() performFly() setFlyBehavior() setQuackBehavior() swim() display() > FlyBehavior fly() FlyWithWings fly() // implements duck flying FlyNoWay fly() // do nothing – Can’t fly > QuackBehavior quack() Quack quack() // implements duck quacking Squeak quack() // implements squeak Mutequack quack() // 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