CSE 403

Design Patterns
 Outline

Introduction to design patterns

Creational patterns (constructing objects)
Structural patterns (controlling heap layout)
Behavioral patterns (affecting object semantics)

Slide 2
 What is a design pattern?

• a standard solution to a common programming problem

– a design or implementation structure that achieves a
particular purpose
– a high-level programming idiom
• a technique
q for making g code more flexible
– reduce coupling among program components
• shorthand for describing program design
– a description
d i i off connections
i among program components
– the shape of a heap snapshot or object model

Slide 3
 Example 1: Encapsulation (data hiding)

Problem: Exposed fields can be directly manipulated

Violations of the representation invariant
Dependences prevent changing the implementation
Solution: Hide some components
Permit onlyy stylized
y access to the object
j
Disadvantages:
Interface may not (efficiently) provide all desired operations
I di i may reduce
Indirection d performance
f

Slide 4
 Example 2: Subclassing (inheritance)

Problem: Repetition in implementations

Similar abstractions have similar members (fields, methods)
Solution: Inherit default members from a superclass
Select an implementation via run-time dispatching
Disadvantages:
Code for a class is spread out, and thus less understandable
Run-time dispatching introduces overhead

Slide 5
 Example 3: Iteration

Problem: To access all members of a collection, must

perform a specialized traversal for each data structure
Introduces undesirable dependences
Does not generalize to other collections
The implementation has knowledge
Solution: about the representation.
p
The implementation performs traversals, does bookkeeping
Results are communicated to clients via a standard interface
Disadvantages:
Di d
Iteration order is fixed by the implementation and not under
the control of the client

Slide 6
 Example 4: Exceptions

Problem:
Errors in one part of the code should be handled elsewhere.
Code should not be cluttered with error-handling
error handling code.
code
Return values should not be preempted by error codes.
Solution: Language
g g structures for throwingg and catchingg
exceptions
Disadvantages:
C d may still
Code ill be
b cluttered.
l d
It may be hard to know where an exception will be
handled.
Use of exceptions for normal control flow may be
confusing and inefficient.

Slide 7
 Example 5: Generics

Problem:
Well-designed data structures hold one type of object
Solution:
Programming language checks for errors in contents
List<Date> instead of jjust List
Disadvantages:
Slightly more verbose types

Slide 8
 Creating generic classes

Introduce a type parameter to a class

public class Graph<N> implements Iterable<N> {
private final Map<N, Set<N>> node2neighbors;
public Graph(Set<N> nodes, Set<Tuple<N,N>> edges) {
...
}
}

public interface Path<N, P extends Path<N,P>>

extends Iterable<N>, Comparable<Path<?, ?>> {
public Iterator<N> iterator();
}

Code can perform any operation permitted by the bound

Slide 9
 Tips for designing generic classes

First, write and test a concrete version

Consider creating a second concrete version
Then, generalize it by adding type parameters
The compiler will help you to find errors

Slide 10
 A puzzle about generics

Integer is a subtype of Number

List<Integer> is not a subtype of List<Number>

Compare specs: add(Integer) is not stronger than add(Number)
What goes wrong if List<Integer> is a subtype of List<Number>?
List<Integer> li = new List<Integer>();
// legal if List<Integer> is subtype of List<Number>
List<Number> ln = li;
ln.add(new Float());
li.get(0); // we got a Float out of a List<Integer>!

Integer[] is a subtype of Number[]

Can we use similar code to break the Java type system?

Slide 11
 When (not) to use design patterns

Get something basic working first

first, then
Rule 1: delay improve it once you understand it.

Design patterns can increase or decrease understandability

Add indirection,
indirection increase code size
Improve modularity, separate concerns, ease description
If your design or implementation has a problem, consider
design patterns that address that problem
Canonical reference: the "Gang of Four" book
Design Patterns: Elements of Reusable Object
Object-Oriented
Oriented
Software, by Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides, Addison-Wesley, 1995.
Another good reference for Java
Effective Java: Programming Language Guide (2nd ed.), by
Joshua Bloch, Addison-Wesley, 2008.

Slide 12
 Why should you care?

You could come up with these solutions on your own

You shouldn't have to!
A design pattern is a known solution to a known problem

Slide 13
 Creational patterns

Constructors in Java are inflexible

Can't return a subtype of the class they belong to
Always return a fresh new object,
object never re-use
re use one

Factories
Factory method
Factory object
Prototype
Sharing
Singleton
Interning
Flyweight

Slide 14
 Factories

Problem: client desires control over object creation

Factory method
Hides decisions about object creation
Implementation: put code in methods in client
Factory object
Bundles factory methods for a family of types
Implementation: put code in a separate object
Prototype
Every object is a factory, can create more objects like itself
Implementation: put code in clone methods

Slide 15
 Motivation for factories: Changing implementations

Supertypes support multiple implementations

interface Matrix { ... }
class SparseMatrix implements Matrix { ... }
class DenseMatrix implements Matrix { ... }

Clients use the supertype (Matrix)

Still need to use a SparseMatrix or DenseMatrix constructor
Switching implementations requires code changes

Slide 16
 Use of factories

Factory
class MatrixFactory {
public static Matrix createMatrix() {
return new SparseMatrix();
}
}
Clients call createMatrix, not a particular constructor
Advantages
Ad
To switch the implementation, only change one place
Can decide what type
yp of matrix to create

Slide 17
 Example: bicycle race

class Race {

// factory method
Race createRace() {

Bicycle bike1 = new Bicycle();

Bicycle
i l bik
bike2
2 = new Bicycle();
i l ()

...
}

Slide 18
 Example: Tour de France

class TourDeFrance extends Race {

// factory method
Race createRace() {
Bicycle bike1 = new RoadBicycle();
Bicycle bike2 = new RoadBicycle();
...
}

Slide 19
 Example: Cyclocross

class Cyclocross extends Race {

// factory method
Race createRace() {
Bicycle bike1 = new MountainBicycle();
Bicycle bike2 = new MountainBicycle();
...
}

Slide 20
 Factory method for Bicycle

class Race {
Bicycle createBicycle() { ... }
Race createRace() {
y
Bicycle bike1 = createBicycle();
y ();
Bicycle bike2 = createBicycle();
...
}
}

Slide 21
 Code using factory methods

class Race {
Bicycle createBicycle() { ... }
Race createRace() {
y
Bicycle bike1 = createBicycle();
y ();
Bicycle bike2 = createBicycle();
...
}
}
class TourDeFrance extends Race {
Bicycle createBicycle() {
y ();
return new RoadBicycle();
}
}
y
class Cyclocross extends Race {
Bicycle createBicycle(Frame) {
return new MountainBicycle();
}
}

Slide 22
 Factory objects/classes encapsulate factory methods

class BicycleFactory {
Bicycle createBicycle() { ... }
Frame createFrame() { ... }
Wheel createWheel() { ... }
...
}

class RoadBicycleFactory extends BicycleFactory {

Bicycle createBicycle() {
return new RoadBicycle();
}
}

class MountainBicycleFactory extends BicycleFactory {

Bicycle createBicycle() {
return new MountainBicycle();
}
}
Slide 23
 Using a factory object

class Race {
BicycleFactory bfactory;
// constructor
Race() { bfactory = new BicycleFactory(); }
Race createRace() {
Bicycle bike1 = bfactory.createBicycle();
Bicycle bike2 = bfactory.createBicycle();
...
}
}

class TourDeFrance extends Race {

// constructor
TourDeFrance() { bfactory = new RoadBicycleFactory(); }
}

class Cyclocross extends Race {

// constructor
Cyclocross() { bfactory = new MountainBicycleFactory(); }
}

Slide 24
 Separate control over bicycles and races

class Race {
BicycleFactory bfactory;
// constructor
Race(Bic cleFactor bfactory)
Race(BicycleFactory bfactor ) { this
this.bfactory
bfactor = bfactory;
bfactor }
Race createRace() {
Bicycle bike1 = bfactory.completeBicycle();
Bicycle bike2 = bfactory.completeBicycle();
...
}
}
// No special constructor for TourDeFrance or for Cyclocross

Now we can specify the race and the bicycle separately:

new TourDeFrance(new TricycleFactory())

Slide 25
 DateFormat factory methods

DateFormat class encapsulates knowledge about how to format dates

and times as text
Options: just date? just time? date+time? where in the world?
Instead of passing all options to constr
constructor,
ctor use
se factories
factories.
Tidy, and the subtype created doesn't need to be specified.

D t F
DateFormat
t df1 = DateFormat.getDateInstance();
D t F t tD t I t ()
DateFormat df2 = DateFormat.getTimeInstance();
DateFormat df3 = DateFormat.getDateInstance(DateFormat.FULL,
Locale.FRANCE);
l C )
Date today = new Date();
System.out.println(df1.format(today)); // “Jul 4, 1776"
System.out.println(df2.format(today)); // "10:15:00 AM"
System.out.println(df3.format(today)); // “juedi 4 juillet 1776"

Slide 26
 Prototype pattern

Every object is itself a factory

Each class contains a clone method that creates a copy of
the receiver object

class Bicyle
y {
Bicycle clone() { ... }
}

You will often see Object as the return type of clone

This is due to a design flaw in Java 1.4 and earlier
clone is declared in Object
Java 1.4 did not permit the return type to change in an
overridden method

Slide 27
 Using prototypes

class Race {
Bicycle bproto;
// constructor
Race(Bic cle bproto) { this
Race(Bicycle this.bproto
bproto = bproto
bproto; }
Race createRace() {
Bicycle bike1 = (Bicycle) bproto.clone();
Bicycle bike2 = (Bicycle) bproto.clone();
...
}
}

Again, we can specify the race and the bicycle separately:

new TourDeFrance(new Tricycle())

Slide 28
 Sharing

Recall the second weakness of Java constructors

Java constructors always return a new object, never a pre-
existing object

Singleton: only one object exists at runtime

Factory method returns the same object every time
g onlyy one object
Interning: j with a p particular (abstract)
value exists at runtime
Factory method returns an existing object, not a new one
Flyweight:
Fl i ht separate t intrinsic
i t i i and d extrinsic
t i i state,
t t representt
them separately, and intern the intrinsic state
Implicit representation uses no space
Slide 29
 Singleton

Only one object of the given type exists

class
l B
Bank
k {
private static bank theBank;

// p
private constructor
private Bank() { ... }

// factory method
public static getBank() {
if (theBank == null) {
theBank = new Bank();
}
return theBank;
}
...
}
Slide 30
 Interning pattern

Reuse existing
R i i objects
bj i
instead
d off creating
i new ones
Less space
Mayy compare
p with == instead of equals()
Permitted only for immutable objects
1-100
(Street-
NumberSet)
"Mass Ave"
(Street- "Mass Ave" (String)
Segment) (String) StreetSegment
with interning 1-100
"O2139" (Street-
(String) NumberSet)
(Street-
StreetSegment Segment)
101-200
without interning 101-200 (Street-
(Street- NumberSet)
NumberSet) (Street-
Segment)
(Street- "Mass Ave"
Segment) (String) "O2139"
(String)

"O2139"
(String)

Slide 31
 Interning mechanism

Maintain a collection of all objects

If an object already appears, return that instead
HashMap<String,
H hM <St i St
String>
i > segnames; // why
h not t SSet<String>?
t<St i >?
String canonicalName(String n) { Set supports
if (segnames.containsKey(n)) { contains but not get
return segnames.get(n);
g g ( )
} else {
segnames.put(n, n);
return n;
}
}

Java builds this in for strings: String.intern()

Two approaches:
– create the object, but perhaps discard it and return another
– check against the arguments before creating the new object
Slide 32
 Failure to use the Interning pattern: java.lang.Boolean

public class Boolean {

private final boolean value;
// construct a new Boolean value
p blic Boolean(boolean value)
public al e) {
this.value = value;
}

public static Boolean FALSE = new Boolean(false);

public static Boolean TRUE = new Boolean(true);
// factory method that uses interning
public static valueOf(boolean value) {
if (value) {
return TRUE;
} else {
return FALSE;
}
}
}

Slide 33
 Recognition of the problem

Javadoc for Boolean constructor:

Allocates a Boolean object representing the value argument.
Note: It is rarely appropriate to use this constructor. Unless a new
instance is required, the static factory valueOf(boolean) is
generally a better choice. It is likely to yield significantly better
space and time performance.
Josh Bloch (JavaWorld, January 4, 2004):
The Boolean type should not have had public constructors. There's
really no great advantage to allow multiple trues or multiple falses,
and I've seen programs that produce millions of trues and millions of
falses, creating needless work for the garbage collector.
So, in the case of immutables, I think factory methods are great.

Slide 34
 Flyweight pattern

Good when many objects are mostly the same

Interning works only if objects are entirely the same (and
immutable!)
Intrinsic state: same across all objects
Technique:
q intern it
Remember that interning requires immutability
Extrinsic state: different for different objects
T h i
Technique: make
k it
i implicit
i li i (don’t
(d ’ even represent it!)
i !)
Making it implicit also requires immutability
Mutable pparts of object
j must still be represented
p explicitly
p y

Slide 35
 Example without flyweight: bicycle spoke

class
l Wh
Wheel
l {
FullSpoke[] spokes;
...
}
class FullSpoke {
int length;
int diameter;
bool tapered;
Metal material;
float weight;
float threading;
bool crimped;
int location; // rim and hub holes this is installed in
}

Typically 32 or 36 spokes per wheel, but only 3 varieties per bicycle.

In a bike race, hundreds of spoke varieties, millions of instances

Slide 36
 Alternatives to FullSpoke

class
l I
IntrinsicSpoke
t i i S k {
int length;
int diameter;
boolean tapered;
Metal material;
float weight;
float threading;
boolean crimped;
}
This doesn't work: it's the same as FullSpoke
class InstalledSpokeFull extends IntrinsicSpoke {
int location;
}
This works,
works but flyweight version uses even less space
class InstalledSpokeWrapper {
IntrinsicSpoke s; // refer to interned object
int location;
}
Slide 37
 Original code to true (align) a wheel

class FullSpoke {
// Tension the spoke by turning the nipple the
// specified number of turns.
void
oid tighten(int turns)
t rns) {
... location ... // location is a field
}
}

class Wheel {
FullSpoke[] spokes;
void align() {
while (wheel is misaligned) {
// tension the ith spoke
... spokes[i].tighten(numturns) ...
}
}
}

Slide 38
 Flyweight code to true (align) a wheel

class IntrinsicSpoke {
void tighten(int turns, int location) {
... location ... // location is a parameter
}
}

class Wheel {
IntrinsicSpoke[] spokes;

void align() {
while (wheel is misaligned) {
// tension the ith spoke
... spokes[i].tighten(numturns, i) ...
}
}
}

Slide 39
 Flyweight discussion

What if FullSpoke contains a wheel field pointing at the

Wheel containing it? Wheel methods pass this to the
methods that use the wheel field.
Wh if FullSpoke contains
What i a boolean broken
b k fi field?
ld?
Add an array of booleans in Wheel,
parallel to the array of Spokess.
Flyweight
Fl i ht is
i manageablebl only
l if there
th are very few
f mutable
t bl
(extrinsic) fields.
Flyweight complicates the code.
code
Use flyweight only when profiling has determined that
space is a serious problem.

Slide 40