cs427a: object-oriented programming - yale...

CS427a: Object-Oriented Programming Design Patterns for Flexible and Reusable design

Michael J. Fischer(from slides by Y. Richard Yang)

Lecture 23bNovember 29, 2011

Example: Duck Game

• A startup produces a duck-pond simulation game

• The game shows a large variety of duck species swimming and making quacking sounds

Initial Design

MillardDuck

display() { looks like a mallard}

RedheadDuck

display() { looks like a redhat}

Other types of ducks

Duck

quack()swim()display() = 0// Other duck-like method

Design Change: add fly()Duck

quack()swim()display() = 0fly()// Other duck-like method

MillardDuck


RedheadDuck


Other types of ducks

Problem• Generalization may lead to

unintended behaviors: a rubber duck is flying and quacks

Duck


RubberDuck

display() {looks like a rubber duck}quack() { // sqeak }fly() { // cannot fly }

MillardDuck


Anticipating Changes

• Identify the aspects of your application that may vary– What may change?

• Anticipate that – new types of ducks may appear and – behaviors (quack, swimming, and flying) may

change, even change at run time (swirl flying, circular flying, …)

Handling Varying Behaviors• Solution: take what varies and “encapsulate”

it– Since fly() and quack() vary across ducks, separate

these behaviors from the Duck class and create a new set of classes to represent each behavior

super class of all ducksVarying and run-time changeable behaviors

Design

• Each duck object has a fly behavior

FlyWithWings

fly() { //}

FlyNoWay

fly() { // cannot fly}

<<interface>>FlyBehavior

fly()

Programming to implementation vs. interface/supertype

• Programming to an implementation– Dog d = new Dog();– d.bark();

• Programming to an interface/supertype– Animal a = new Dog();– a.makeSound();

Implementation

FlyWithWings

fly() { //}

FlyNoWay

fly() { // cannot fly}

<<interface>>FlyBehavior

fly()

MallardDuck


RedheadDuck


Duck


Exercise

• Add rocket-powered flying?

The Strategy Pattern

• Defines a set of algorithms, encapsulates each one, and makes them interchangeable by defining a common interface

Exercise

Summary: Design Principles

• Identify the aspects of your application that vary and separate them from what stay the same

• Program to an interface not implementation

• Favor composition over inheritance

Example: KitchenViewer Interface

Wallcabinet

Counter

Floorcabinet

Modern Classic Antique Arts & Crafts

menu

display area

styles

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

KitchenViewer Example


Wall cabinets Floor cabinetsCountertop

Selecting Antique Style


KitchenViewer Using Standard Inheritance

Kitchen

ClientrenderKitchen()

FloorCabinet

ModernWallCabinet

ModernFloorCabinet AntiqueFloorCabinet

AntiqueWallCabinet

WallCabinet

Aspect of the system thatmay change/vary?

: Reference direction

AntiqueKStylegetWallCabinet()getFloorCabinet()

The Abstract Factory Idea

KitchenStylegetWallCabinet()getFloorCabinet()

ModernKStylegetWallCabinet()getFloorCabinet()

WallCabinet FloorCabinet

AntiqueWallCabinet AntiqueFloorCabinet

FloorCabinet getFloorCabinet() { return new AntiqueFloorCabinet(); }

……

FloorCabinet getFloorCabinet() { return new ModernFloorCabinet(); }

Abstract Factory Design Pattern Applied to KitchenViewer

KitchenStylegetWallCabinet()getFloorCabinet()

KitchengetWallCabinet()getFloorcabinet()

ClientrenderKitchen( KitchenStyle )



AntiqueKStylegetWallCabinet()getFloorCabinet()

WallCabinet FloorCabinet

ModernWallCabinet

ModernFloorCabinet

AntiqueWallCabinet

AntiqueFloorCabinet

Abstract Factory Design Pattern

StylegetComponentA()getComponentB()

ClientdoOperation( Style myStyle )

Style1getComponentA()getComponentB()


ComponentA ComponentB

Style1ComponentA

Style1ComponentB

Style2ComponentA

Style2ComponentB

Collection

Concrete and Abstract Layers

KitchenStyle

Kitchen

Client

ModernKStyle

AntiqueKStyle

WallCabinet

FloorCabinet

ModernWallCabinet

ModernFloorCabinet

AntiqueWallCabinet

AntiqueFloorCabinet

Abstract level

Concrete level

getWallCabinet()

Abstract Factory Application Sequence Diagram

myStyle:KitchenStyleClient

myStyle:ModernKStyle

myStyle:AntiqueKStyle

renderKitchen( myStyle )

wallCabinet1:ModernWallCabinet

wallCabinet1:AntiqueWallCabinet

ModernWallCabinet()getWallCabinet()

AntiqueWallCabinet()

myStyle.getWallCabinet()

-- IF myStyle BELONGS TO ModernKStyle --

-- IF myStyle BELONGS TO AntiqueKStyle --

Potential use of this Design Pattern?

StylegetComponentA()getComponentB()

ClientdoOperation( Style myStyle )



ComponentA ComponentB

Style1ComponentA

Style1ComponentB

Style2ComponentA

Style2ComponentB

Collection

References

• Design Patterns

• Headfirst Design Patterns

• Software Design

Example: Starbuzz Coffee

• The coffee shop offers a variety of beverages

HouseBlend

cost()

Beverage

description

getDescription();cost();// Other methods

DarkRoast

cost()

Decaf

cost()

Espresso

cost()

Problem

• A customer may also ask for condiments– steamed milk– soy– mocha (otherwise known as chocolate)– whipped milk

• Starbuzz charges a bit for each of these

HouseBlend

cost()

Beverage

descriptionmilksoymochawhip

getDescription();cost();

hasMilk(); setMilk();hasSoy(); setSoy();hasMocha(); setMocha();hasWhip(); setWhip();

// Other methods

DarkRoast

cost()

Decaf

cost()

Espresso

cost()

Aspect of the system thatmay change/vary?

Attempt 1

Potential Changes

• Potential changes:– Price change to condiments– New condiments– Double moca– …

Design idea

• Basic idea: extension at run time, not compile time

• Definition: The Decorator pattern attaches additional features to an object dynamically. It provides a flexible alternative to subclassing for extending functionality

Design approach 1

• Each beverage contains a dynamic list of condiments

• Example– Take a DarkRoast object– Decorate it with a Mocha object– Decorate it with a Whip object

UML class model?

Decorator design

• Example– Take a DarkRoast object– Decorate it with a Mocha object– Decorate it with a Whip object– Call the cost() method and rely on delegation to

add on the condiment cost

• Decorator adds its own behavior before or after calling the decorated object

Decoration Delegation Process

Decorator Class Model

Client

objDecorated

DecoratordoAction()

1

ConcreteComponentdoAction()

ComponentdoAction()

void doAction(){ ….. // do actions special to this decoration objDecorated.doAction(); // pass along}


ConcreteDecoratorAdoAction()

ConcreteDecoratorBdoAction()

Sequence Diagram for Decorator

:Client

doAction()

decoration1:Decoration

doAction()

Decoration1.objDecorated:Decoration

:Component

doAction()


Decoration Features

• Decorators have the same supertype as the objects they decorate

• You can use one or more decorators to wrap an object– Thus, you can pass decorated object in place of

original (wrapped) object• The decorator adds its own behavior either

before or after delegating to the object it decorates to

• Objects can be decorated at any time, including run-time, with as many decorators as possible

Exercise

• Suppose we allow different sizes for the beverages– Tall (small)– Grande (medium)– Venti (large)

Some Common Design Patterns

Example: Weather-O-Rama

Weather-O-Rama

Weather-O-Rama InterfaceWeatherData

getTemperature();getHumidity();getPressure();measurementsChanged();setMeasurements(); // other methods

This method gets called wheneverthe weather measurements have been updated.

First Implementationvoid 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) ;

}

By coding to concrete implementation, we have no way of allowing other displays and plug in.

Observer Pattern

• Design Purpose: defines a run-time, one-to-many dependency between objects so that when one object (the subject) changes state, all of the dependents (observers) are notified.

Observer Design Pattern

SubjectregisterObserver();removeObserver();notifyObservers();

Observerupdate()

ConcreteSubjectgetState();setState();

ConcreteObserver

update()

for all Observer’s o: o.update();

Client1..n

Server part Client part

How does Observer apply these design principles?

• Identify the aspects of your application that vary and separate them from what stay the same

• Program to an interface not implementation

• Favor composition over inheritance

Discussion

• Java Observation design: update(Observable o, Object obj);


Observerupdate()


ConcreteObserver

update()


1..n


Observerupdate()


ConcreteObserver

update()


Client1..n

cs427a: object-oriented programming - yale...

Documents