1. CS 210
Review
October 3, 2006

2. Introduction to Design Patterns
Chapter 1
Strategy Pattern

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

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

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

6. 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?

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

8. In the Duck simulation context…
Parts that vary
Parts that stay the same
Duck
Behaviors
Flying Behaviors
Duck Class
Quacking Behaviors

9. Design Principle Program to an interface, not to an implementation.
Really means program to a super type.

10. 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 }

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

12. In the Duck simulation context…
FlyBehavior: flyBehavior
QuackBehavior: quackBehavior
performQuack()
swim()
display()
performFly()
//other duck-like methods
Duck
Behaviors
Flying Behaviors
Quacking Behaviors

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

14. Design Principle Favor composition over inheritance
HAS-A can be better than IS-A
Allows changing behavior at run time

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

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

17. 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()

18. Head First Design Patterns
Chapter 2
Observer Pattern

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

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

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

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

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

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

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

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

27. 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]

28. 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()

29. 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();

30. 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(); }

31. 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);

32. 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();

33. Observer pattern
More analysis

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

35. 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()

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

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

38. Head First Design Patterns
Chapter 3
Decorator Pattern

39. 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?

40. Page 81
Head First
Design Patterns

41. Beverage class redone
Page 83
Head First
Design Patterns

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

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

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

45. Decorator Pattern approach
Page 89
Head First
Design Patterns

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

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

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

49. Decorator Pattern for Beverage Example
Page 92
Head First
Design Patterns

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