Chapter 1: Introduction to Design Patterns

SimUDuck Example

quack()swim()display()

Duck

display()

Mallard

display()

RedheadDuck other ducks...

System Update

• Revise the current system to cater for ducks that fly. How can this be done?

A Possible Solution

quack()swim()fly()display()

Duck

display()

MallardDuck

display()

RedheadDuckother ducks...

Suppose that a RubberDuckclass needs to be added?

Revision: Use Inheritance?

quack()swim()fly()display()

Duck

display()

MallardDuck

display()

RedheadDuck

display()

RubberDuck

quack()fly()

Suppose that you have to add a decoy duck that does not fly or quack…

Another Solution: Interfaces

• The aspects that change for each type of duck are the methods fly() and quack().

• Take these methods out of the Duck class.• Create interfaces for these methods:

– Flyable – has a method fly()– Quackable – has a method quack()

Using Interfaces

swim()display()

Duck

display()fly()quack()

MallardDuck

display()fly()quack()

RedheadDuck

display()

RubberDuck

quack()

fly()

Flyable

quack()

Quackable

display()

DecoyDuck

Problems with this?

Disadvantages of the Approach

• All methods in Java interfaces are abstract.• Code has to be duplicated for classes.• Modification will have to be made to more

than one class.• This will introduce bugs.

Design Principle

• Identify the aspects of the application that vary and separate them from what stays the same.

• Encapsulate the parts that vary.• Future changes can be made without affecting

parts that do not vary.• Results in fewer unexpected consequences

from code change.

Solution

• Design principle: Program to interface and not to implementation.

• An interface FlyBehavior will be implemented by subclasses for different types of flight.

• An interface Quackable will be implemented for different types of “quack”.

Example

makeSound()

Animal

makeSound()

Dog

makeSound()

Cat

Abstract class OR Interface

FlyBehavior Interface

FlyBehavior

FlyWithWings FlyNoWay

fly()

fly()fly()

QuackBehavior

QuackBehavior

Quack Squeak

quack()

quack()quack()

MuteQuack

quack()

New Design

swim()display()performFly()performQuack()

Duck

display()

MallardDuck

display()

RedheadDuck

display()

RubberDuck

display()

DecoyDuck

fly()

FlyBehvior<<interface>>

quack()

QuackBehvior<<interface>>has a

has a

On Last Problem• Still programming to implementation in the

subclasses.• Solution – include set methods in the Duck

class– To set quack behavior– To set fly behavior

• The set methods allow for behavior to be dynamic at runtime

Exercise• Add a new type of duck to the simulator,

namely, model duck. A model duck does not fly and quacks.

• Add a new fly behavior to the simulator, namely, FlyRocketPower, which represents flight via a rocket.

• Create an instance of a model duck and change its behaviour at runtime to be flight via a rocket.

Has-A Can be Better than Is-A

• Inheritance promotes reuse but not extensibility.

• Composition facilitates more flexibility.• Composition allows for behavior to change at

runtime (rather than editing code).• Design principle: Favor composition over

inheritance.

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.

Lessons Learned from the Strategy Pattern

• Encapsulate what varies.• Favor composition over inheritance.• Program to interfaces, not implementations

Advantages of Sharing a Pattern Vocabulary

• Shared pattern vocabularies are powerful.• Patterns allow you to say more with less.• Talking at the pattern level allows to stay “in

design” longer.• Shared vocabularies can turbo charge your

development.• Shared vocabularies encourage more junior

developers to get up to speed.