Design Patterns

1
What are Design Patterns?

Design patterns describe common (and

successful) ways of building software.

2
What are Design Patterns?

“A pattern describes a problem that occurs often,

along with a tried solution to the problem”
- Christopher Alexander, 1977

• Idea: Problems can be similar, therefore,

solutions can also be similar.
– Not individual classes or libraries
• Such as lists, hash tables
– Not full designs
– Often rely on Object-Oriented languages 3
Real-World Example: the “door” pattern

• System Requirements:
– Portal between rooms
– Must be able to open and close

• Solution:
– Build a door

4
 Real-World Example: the “door” pattern

• Doors have multiple components

– “main” part
– “hinge” part
– “rail” part
– “handle” part

The design pattern specifies

how these components interact
to solve a problem
5
 Real-World Example: the “door” pattern

• The “door” design pattern is easy to reuse

• The implementation is different every time, the

design is reusable.

6
Advantages

• Teaching and learning

– It is much easier to learn the code architecture
from descriptions of design patterns than from
reading code

• Teamwork
– Members of a team have a way to name and discuss
the elements of their design

7
What design patterns are not

• Not an architecture style:

– Does not tell you how to structure the entire
application
• Not a data structure
– e.g. a hash table
• Not an algorithm
– e.g. quicksort

8
References and resources

• GoF Design Patterns book:

– http://c2.com/cgi/wiki?DesignPatternsBook
– https://catalog.swem.wm.edu/Record/3301458
• Head First Design Patterns:
– http://shop.oreilly.com/product/9780596007126.do
– https://catalog.swem.wm.edu/Record/3302095
• Design Patterns Quick Reference Cards:
– http://www.mcdonaldland.info/files/
designpatterns/designpatternscard.pdf
9
• Check SWEM: “Software design patterns”
Software Design Patterns from CS 301

1. Iterator also in Horstmann’s book

2. Observer • Adapter
3. Strategy • Command
4. Composite • Factory
5. Decorator • Proxy
6. Template • Visitor
7. Singleton

10
Software Example: A Text Editor

• Describe a text editor using patterns

– A running example

• Introduces several important patterns

Note: This example is from the book “Design

Patterns: Elements of Reusable Object-
Oriented Software”, Gamma, et al. : GoF book
9
Text Editor Requirements

• A WYSIWYG editor
• Text and graphics can be freely mixed
• Graphical user interface
• Toolbars, scrollbars, etc.

• Traversal operations: spell-checking

• Simple enough for one lecture!

10
The Game

• I describe a design problem for the editor

• I ask “What is your design?”

– This is audience participation time

• I give you the wise and insightful pattern

11
Problem: Document Structure

A document is represented by its physical structure:

– Primitive glyphs: characters, rectangles, circles, pictures, . . .
– Lines: sequence of glyphs
– Columns: A sequence of lines
– Pages: A sequence of columns
– Documents: A sequence of pages

• Treat text and graphics uniformly

– Embed text within graphics and vice versa

• No distinction between a single element or a group of

elements
– Arbitrarily complex documents
What is your design? 12
A Design

• Classes for Character, Circle, Line, Column, Page, …

– Not so good
– A lot of code duplication

• One (abstract) class of Glyph

– Each element realized by a subclass of Glyph
– All elements present the same interface
• How to draw
• Mouse hit detection
• …
– Makes extending the class easy
– Treats all elements uniformly 13
 Example of Hierarchical Composition

character picture
glyph G g glyph

line glyph
(composite)

column glyph
(composite)
14
Logical Object Structure

15
 Diagram

Glyph
draw()
n
intersects(int x,int y)

…
children

Character Picture Line

draw() draw() draw() …
intersects(int x,int y) intersects(int x,int y) intersects(int x,int y)

… … …

16
 Composite Pattern

The Composite pattern teaches

how to combine several objects into an object
that has the same behavior as its parts.

19
Composites

• This is the composite pattern

– Composes objects into tree structure
– Lets clients treat individual objects and
composition of objects uniformly
– Easier to add new kinds of components

17
Problem: Supporting Look-and-Feel Standards

• Different look-and-feel standards

– Appearance of rectangles, characters, etc.

• We want the editor to support them all

– What do we write in code like
Character ltr = new ?

What is your design? 18

Possible Designs

• Terrible • Little better

Character ltr = new MacChar(); Character ltr;
if (style == MAC)
scr = new MacChar();
else if (style == WINDOWS)
scr = new WinChar();
else if (style == …)
….

19
Abstract Object Creation

• Encapsulate what varies in a class

• Here object creation varies
– Want to create different character, rectangle, etc
– Depending on current look-and-feel

• Define a GUIFactory class

– One method to create each look-and-feel
dependent object
– One GUIFactory object for each look-and-feel
– Created itself using conditionals 20
 Diagram

GuiFactory
CreateCharacter()

CreateRectangle()

MacFactory WindowsFactory …
CreateCharacter() { CreateCharacter() {

return new MacChar();} return new WinChar();}

CreateRectangle() { CreateRectangle() {

return new MacRect();} return new WinRect();} 21

Diagram 2: Abstract Products

Glyph

Character

MacChar WinChar …

22
Factory Pattern

• A class which
– Abstracts the
creation of a
family of objects
– Different
instances provide
alternative
implementations
of that family

• Note
– The “current” factory is still a global variable
– The factory can be changed even at runtime 23
Problem: Spell Checking

• Considerations
– Spell-checking requires traversing the document
• Need to see every glyph, in order
• Information we need is scattered all over the document

– There may be other analyses we want to perform

• E.g., grammar analysis

What is your design?

24
One Possibility

• Iterators
– Hide the structure of a container from clients
– A method for
• pointing to the first element
• advancing to the next element and getting the current
element
• testing for termination
Iterator i = composition.getIterator();
while (i.hasNext()) {
Glyph g = i.next();
25
do something with Glyph g;
Diagram

Iterator
hasNext()

next()

PreorderIterator ListIterator
hasNext() hasNext()

next() next()

26
Notes

• Iterators work well if we Iterator i = composition.getIterator();

while (i.hasNext()) {
don’t need to know the
Glyph g = i.next();
type of the elements if (g instanceof Character) {
being iterated over // analyze the character
– E.g., send kill message to } else if (g instanceof Line) {

all processes in a queue // prepare to analyze children

of
• Not a good fit for spell- // row
checking } else if (g instanceof Picture) {

– Ugly // do nothing
} else if (…) …
– Change body whenever the
}
class hierarchy of Glyph
27
changes
Visitors

• The visitor pattern is more general

– Iterators provide traversal of containers
– Visitors allow
• Traversal
• And type-specific actions

• The idea
– Separate traversal from the action
– Have a “do it” method for each element type
• Can be overridden in a particular traversal 28
 Diagram

Glyph Visitor
accept(Visitor) visitChar(Character)

… visitPicture(Picture)

visitLine(Line)

Line
Character Picture …
accept(Visitor v) {
accept(Visitor v) { accept(Visitor v) {
v.visitLine(this);
v.visitChar(this); } v.visitPicture(this); }
for each c in children

c.accept(v) } 29
Visitor Pattern

Visitor Pattern

33
Logical Object Structure

30
Java Code

abstract class Glyph { abstract class Visitor {

abstract void accept(Visitor vis); abstract void visitChar (Character c);

… abstract void visitLine(Line l);

abstract void visitPicture(Picture p);
}
…
class Character extends Glyph {
}
…
class SpellChecker extends Visitor {
void accept(Visitor vis) {
void visitChar (Character c) {
vis.visitChar(this); // analyze character}
} void visitLine(Line l) {
} // process children }

class Line extends Glyph { void visitPicture(Picture p) {

… // do nothing }
… 31
void accept(Visitor vis) {
} Prof. Majumdar CS 130 Lecture 6
 Java Code

SpellChecker checker = new abstract class Visitor {

SpellChecker(); abstract void visitChar (Character c);
Iterator i = composition.getIterator();
abstract void visitLine(Line l);
while (i.hasNext()) {
abstract void visitPicture(Picture p);
Glyph g = i.next();
…
g.accept(checker);
} }
class SpellChecker extends Visitor {
void visitChar (Character c) {
// analyze character}
void visitLine(Line l) {
// process children }
void visitPicture(Picture p) {
32
// do nothing }
Prof. Majumdar CS 130 Lecture 6
Problem: Formatting

• A particular physical structure for a document

– Decisions about layout
– Must deal with e.g., line breaking

• Design issues
– Layout is complicated
– No best algorithm
• Many alternatives, simple to complex

What is your design? 33

A First Shot:

• Add a format method to each Glyph class

• Not so good
• Problems
– Can’t modify the algorithm without modifying Glyph
– Can’t easily add new formatting algorithms

34
The Core Issue

• Formatting is complex
– We don’t want that complexity to pollute Glyph
– We may want to change the formatting method

• Encapsulate formatting behind an interface

– Each formatting algorithm an instance
– Glyph only deals with the interface

35
Formatting Examples

We've settled on a way We've settled on a way

to represent the to represent the
document's physical document's physical
structure. Next, we structure. Next, we
need to figure out how need to figure out how
to construct a particular to construct a particular
physical structure, one physical structure, one
that corresponds to a that corresponds to a
properly formatted properly formatted
document. document.
36
 Diagram

Glyph FormatSimple
draw() Compose()
Glyph::insert(g)
intersects(int x,int y) formatter.Compose() …
insert(Glyph)

1 Formatter
Compose()

…
FormatJustified
Composition formatter
draw()
Compose()
intersects(int x, int y)
composition …
insert(Glyph g)
37
Not clear?

• This is were the pattern idea helps

communication!
• Let’s understand the pattern first:

42
Strategy Pattern

43
Strategies

• This is the strategy pattern

– Isolates variations in algorithms we might use
– Formatter is the strategy, Composition is context
• The GoF book says the Strategy design pattern should: “Define
a family of algorithms, encapsulate each one, and make them
interchangeable. Strategy lets the algorithm vary independently
from clients that use it.”
• General principle
encapsulate variation
• In OO languages, this means defining abstract classes
for things that are likely to change 39
 Diagram: Strategy = Formatter

Glyph FormatSimple
draw() Compose()
Glyph::insert(g)
intersects(int x,int y) formatter.Compose() …
insert(Glyph)

1 Formatter
Compose()

…
FormatJustified
Composition formatter
draw()
Compose()
intersects(int x, int y)
composition …
insert(Glyph g)
37
Formatter

Formatter-
generated
Glyphs

Formatter

38
Design Patterns Philosophy

• Program to an interface and not to an

implementation

• Encapsulate variation

• Favor object composition over inheritance

40
Acknowledgements

• Many slides courtesy of Rupak Majumdar

• Some from Cay Horstmann 

41