CS 210 Review October 3, 2006

Introduction to Design Patterns Chapter 1 Strategy Pattern

Simple Simulation of Duck behavior quack() swim() display() // other duck methods RedheadDuck MallardDuck display() // looks like redhead Other duck types display() // looks like mallard

What if we want to simulate flying ducks? quack() swim() display() fly() // other duck methods RedheadDuck MallardDuck display() // looks like redhead Other duck types display() // looks like mallard

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

Example complicated: add a wooden decoy ducks to the mix 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?

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.

Implementing duck behaviors - revisited <<interface>> FlyBehavior fly() <<interface>> QuackBehavior quack() MuteQuack quack(){ // do nothing – Can’t quack } Quack quack(){ // implements duck quacking } FlyWithWings fly(){ // implements duck flying } FlyNoWay fly(){ // do nothing – Can’t fly } Squeak quack(){ // implements duck squeak }

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… FlyBehavior: flyBehavior QuackBehavior: quackBehavior performQuack() swim() display() performFly() //other duck-like methods Duck Behaviors Flying Behaviors Quacking Behaviors

Duck simulation recast using the new approach <<interface>> FlyBehavior fly() Duck FlyBehavior: flyBehavior QuackBehavior: quackBehavior performQuack() performFly() setFlyBehavior() setQuackBehavior() swim() display() FlyWithWings fly() // implements duck flying FlyNoWay fly() // do nothing – Can’t fly <<interface>> QuackBehavior quack() Quack quack() // implements duck quacking Squeak quack() // implements squeak MallardDuck display() RedHeadDuck display() RubberDuck display() DecoyDuck display() 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

Behavior Interface Abstract <<interface>> WeaponBehavior useWeapon() Character WeaponBehavior weapon; fight(); setWeapon(WeaponBehavior w){ this.weapon = w; } BowAndArrowBehavior useWeapon() //implements fight with // bow and arrows AxeBehavior useWeapon() //implements fight with // an axe King fight() Knight fight() KnifeBehavior useWeapon() //implements cutting with // a knife SpearBehavior useWeapon() //implements fight with // a spear Bishop fight() Queen fight()

Head First Design Patterns Chapter 2 Observer Pattern

Weather Monitoring Application Humidity Sensor Pulls Data Weather Station displays Weather Data Object Display Device Temp Sensor Pressure Sensor

What needs to be done? Update three different displays /* WeatherData getTemperature() getHumidity() getPressure() measurementsChanged() /* * Call this method * whenever measurements are * Updated */ Public void measurementsChanged(){ // your code goes here } Update three different displays

Problem specification weatherData class has three getter methods measurementsChanged() method called whenever there is a change Three display methods needs to be supported: current conditions, weather statistics and simple forecast System should be expandable

First cut at implementation public class WeatherData { public void measurementsChanged(){ float temp = getTemperature(); float humidity = getHumidity(); float pressure = getPressure(); currentConditionsDisplay.update (temp, humidity, pressure); statisticsDisplay.update (temp, humidity, pressure); forecastDisplay.update (temp, humidity, pressure); } // other methods

First cut at implementation public class WeatherData { public void measurementsChanged(){ float temp = getTemperature(); float humidity = getHumidity(); float pressure = getPressure(); currentConditionsDisplay.update (temp, humidity, pressure); statisticsDisplay.update (temp, humidity, pressure); forecastDisplay.update (temp, humidity, pressure); } // other methods Area of change which can be Managed better by encapsulation By coding to concrete implementations there is no way to add additional display elements without making code change

Basis for observer pattern Fashioned after the publish/subscribe model Works off similar to any subscription model Buying newspaper Magazines List servers

Observer Pattern Defined The Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically.

Observer Pattern – Class diagram <<interface>> Subject registerObserver() removeObserver() notifyObservers() observers <<interface>> Observer Update() subject ConcreteObserver Update() ConcreteSubject registerObserver() removeObserver() notifyObservers()

Observer pattern – power of loose coupling The only thing that the subject knows about an observer is that it implements an interface Observers can be added at any time and subject need not be modified to add observers Subjects and observers can be reused or modified without impacting the other [as long as they honor the interface commitments]

Observer Pattern – Weather data <<interface>> Observer update() observers <<interface>> DisplayElement display() <<interface>> Subject registerObserver() removeObserver() notifyObservers() CurrentConditionsDisplay update() display() StatisticsDisplay update() display() subject WeatherData registerObserver() removeObserver() notifyObservers() getTemperature() getPressure() measurementsChanged() ForecastDisplay update() display()

Weather data interfaces public interface Subject { public void registerObserver(Observer o); public void removeObserver(Observer o); public void notifyObservers(); } public interface Observer { public void update(float temp, float humidity, float pressure); public interface DisplayElement { public void display();

Implementing subject interface public class WeatherData implements Subject { private ArrayList observers; private float temperature; private float humidity; private float pressure; public WeatherData() { observers = new ArrayList(); }

Register and unregister public void registerObserver(Observer o) { observers.add(o); } public void removeObserver(Observer o) { int i = observers.indexOf(o); if (i >= 0) { observers.remove(i);

Notify methods public void notifyObservers() { for (int i = 0; i < observers.size(); i++) { Observer observer = (Observer)observers.get(i); observer.update(temperature, humidity, pressure); } public void measurementsChanged() { notifyObservers();

Observer pattern More analysis

Push or pull The notification approach used so far pushes all the state to all the observers One can also just send a notification that some thing has changed and let the observers pull the state information Java observer pattern support has built in support for both push and pull in notification

Java Observer Pattern – Weather data <<interface>> Observer update() observers <<interface>> DisplayElement display() Observable addObserver() deleteObserver() notifyObservers() setChanged() Observable is a class And not an interface CurrentConditionsDisplay update() display() StatisticsDisplay update() display() subject WeatherData registerObserver() removeObserver() notifyObservers() getTemperature() getPressure() measurementsChanged() ForecastDisplay update() display()

Java implementation Look at API documentation java.util.Observable java.util.Observer Look at weather station re-implementation

Summary so far.. Observer pattern defines one-to-many relationship between objects You can use push or pull with observer pattern Java has several implementations of observer pattern – in util, swing, javabeans and RMI Swing makes heavy use of this pattern

Head First Design Patterns Chapter 3 Decorator Pattern

A coffee shop example… Beverage description getDescription() Cost() Decaf cost() Espresso cost() DarkRoast cost() HouseBlend cost() What if you want to show the addition of condiments such as steamed milk, soy, mocha and whipped milk?

Page 81 Head First Design Patterns

Beverage class redone Page 83 Head First Design Patterns

Potential problems with the design so far? Solution is not easily extendable How to deal with new condiments Price changes New beverages that may have a different set of condiments – a smoothie? Double helpings of condiments

Design Principle The Open-Closed Principle Classes should be open for extension, but closed for modification.

The Decorator Pattern Take a coffee beverage object – say DarkRoast object Decorate it with Mocha Decorate it with Whip Call the cost method and rely on delegation to correctly compute the composite cost

Decorator Pattern approach Page 89 Head First Design Patterns

Computing Cost using the decorator pattern Page 90 Head First Design Patterns

Decorator Pattern The decorator pattern attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to sub-classing for extending functionality.

Decorator Pattern Defined Page 91 Head First Design Patterns Decorator Pattern Defined

Decorator Pattern for Beverage Example Page 92 Head First Design Patterns

Summary so far.. OO Basics OO Principles OO Patterns Abstraction Encapsulation Inheritance Polymorphism OO Principles Encapsulate what varies Favor composition over inheritance Program to interfaces not to implementations Strive for loosely coupled designs between objects that interact Classes should be open for extension but closed for modification. OO Patterns 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. Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically. Decorator Pattern – attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative for sub-classing for extending functionality