Informatics 122

Software Design II
Lecture 5
Emily Navarro

Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited.

Portions of the slides in this lecture are adapted from

http://www.cs.colorado.edu/~kena/classes/5448/f12/
lectures/

1
 Announcement

• Be sure to turn in the original design (created by

the designer, not you) with your Assignment 2
 Today’s Lecture

• Design patterns – part 2 of a 3-part series

• Two patterns:
• Factory Method
• Abstract Factory

• Further reflection on MakeAGraph designs

 Factory Patterns: The Problem
with “new”
• Each time we use the “new” command we break encapsulation
• Duck duck = new DecoyDuck();

• Even though our variable uses an “interface”, this code depends on

“DecoyDuck”

• In addition, if you have code that instantiates a particular subtype based on the
current state of the program, then the code depends on each concrete class

if (hunting) {
return new DecoyDuck() Obvious problems:
} else { needs to be recompiled each time a
return new RubberDuck() dependent changes;
} add new classes -> change this code
remove existing classes -> change this
code
 PizzaStore Example

• We have a pizza store program that wants to

separate the process of creating a pizza from the
process of preparing/ordering a pizza
• Initial code: mixes the two processes (see next
slide)
 Encapsulate Creation Code

• A simple way to encapsulate this code is to put it

in a separate class
• That new class depends on the concrete classes, but
those dependencies no longer impact the preparation
code
• See example next slide
9
PizzaTestDrive.java
Demo
 Class Diagram of New Solution

Pizza

While this is nice, it is not as flexible as it can be: to increase flexibility we

need to look at two design patterns: Factory Method and Abstract Factory
 Factory Method
• To demonstrate the FactoryMethod pattern, the pizza store example
evolves
• to include the notion of different franchises
• that exist in different parts of the country (California, New York, Chicago)

• Each franchise needs its own factory to match the proclivities of the locals
• However, we want to retain the preparation process that has made PizzaStore
such a great success

• The Factory Method design pattern allows you to do this by

• placing abstract “code to an interface” code in a superclass
• placing object creation code in a subclass

• PizzaStore becomes an abstract class with an abstract createPizza()

method

• We then create subclasses that override createPizza() for each region

New PizzaStore Class
Factory Method
This class is a (very simple) OO
framework. The framework provides
one service: “order pizza.”
The framework invokes the
createPizza factory method to create a
pizza that it can then prepare using a
well-defined, consistent process.
A “client” of the framework will
subclass this class and provide an
implementation of the createPizza
method.
Any dependencies on concrete
“product” classes are encapsulated in
the subclass.
 New York Pizza Store

Nice and simple. If you want a NY-style pizza, you create an instance of
this class and call orderPizza() passing in the type. The subclass makes
sure that the pizza is created using the correct style.

If you need a different style, create a new subclass.

Chicago Pizza Store
 A couple of the
concrete product
classes

17
Demo
 Factory Method: Definition and
Structure
• The Factory Method design pattern defines an interface
for creating an object, but lets subclasses decide which
class to instantiate. Factory Method lets a class defer
instantiation to subclasses.

Factory Method leads to the creation of parallel class hierarchies; ConcreateCreators

produce instances of ConcreteProducts that are operated on by Creators via the
Product interface
 How about a Duck Factory?
<<interface>> <<interface>>
flyBehavior quackBehavior
FlyBehavior QuackBehavior
fly() quack()

Duck
swim()
display()
setFlyBehavior(FlyBehavio
FlyWithWings CantFly r) Silence Quack Squeak
fly() fly() setQuackBehavior(QuackB quack() quack() quack()
ehavior)
performFly()
performQuack()

MallardDuck RedheadDuck RubberDuck DecoyDuck

display() display() display() display()
 Moving On

• The factory method approach to the pizza store is a big

success, allowing our company to create multiple
franchises across the country quickly and easily
• But (bad news): we have learned that some of the franchises
• while following our procedures (the abstract code in PizzaStore
forces them to)
• are skimping on ingredients in order to lower costs and increase
margins
• Our company’s success has always been dependent on the
use of fresh, quality ingredients
• So, something must be done!
 Abstract Factory to the
Rescue!
• We will alter our design such that a factory is used to
supply the ingredients that are needed during the pizza
creation process
• Since different regions use different types of ingredients,
we’ll create region-specific subclasses of the ingredient
factory to ensure that the right ingredients are used
• But, even with region-specific requirements, since we are
supplying the factories, we’ll make sure that ingredients
that meet our quality standards are used by all franchises
• They’ll have to come up with some other way to lower costs.
 First, we Need a Factory
Interface

Note the introduction of more abstract classes: Dough, Sauce, Cheese, etc.
Second, we Implement a
Region-Specific Factory
This factory ensures that quality
ingredients are used during the
pizza creation process…

… while also taking into account

the tastes of people in Chicago

But how (or where) is this factory

used?
 Within Pizza Subclasses… (I)

First, alter the Pizza abstract base class to make the prepare method
abstract…
 Within Pizza Subclasses… (II)

Then, update pizza subclasses to make use of the factory! Note: we no

longer need subclasses like NYCheesePizza and ChicagoCheesePizza because
the ingredient factory now handles regional differences
 One Last Step…

We need to update our PizzaStore subclasses to create the

appropriate ingredient factory and pass it to each Pizza subclass within
the createPizza method
 Summary: What did we just
do?
• We created an ingredient factory interface to allow for the creation
of a family of ingredients for a particular pizza

• This abstract factory gives us an interface for creating a family of

products (e.g., NY pizzas, Chicago pizzas)
• The factory interface decouples the client code from the actual factory
implementations that produce context-specific sets of products

• Our client code (PizzaStore) can then pick the factory appropriate
to its region, plug it in, and get the correct style of pizza (Factory
Method) with the correct set of ingredients (Abstract Factory)
Demo
Class Diagram of Abstract
Factory Solution

30
 Abstract Factory: Definition
and Structure
• The Abstract Factory design pattern provides an
interface for creating families of related or dependent
objects without specifying their concrete classes
 Abstract Factory
Characteristics
• Isolates concrete classes

• Makes exchanging product families easy

• Promotes consistency among products

Real Life Example
Back to Design Aesthetics for a
Bit…

• What makes a given software implementation design

“beautiful”?

• What is it that makes someone appreciate a particular

software implementation design?

• What are the qualities that determine whether a particular

software implementation design is “good” or “bad”?

• What is it, then, that we can strive for in creating a software

implementation design that will help others in appreciating it?
 Purpose of Implementation
Design

• An implementation design is a road map

• An implementation design describes a path from

application / interaction / architecture design to the
product

• An implementation design describes what the

implementers should do

• An implementation design is a guide towards future

change
 Purpose of Implementation
Design
• An implementation design is a road map
• understandable, unambiguous, consistent, helpful, …

• An implementation design describes a path from application /

interaction / architecture design to the product
• correct, complete, concise, verifiable, effective, …

• An implementation design describes what the implementers should do

• elegant, partitionable, recomposable, resilient, …

• An implementation design is a guide towards future change

• evolvable, …
 More of a Shared
Understanding (Not Perfect!)
• An implementation design is a road map
• understandable, unambiguous, consistent, helpful, …

• An implementation design describes a path from

application / interaction / architecture design to the product
• correct, complete, concise, verifiable, effective, …

• An implementation design describes what the implementers

should do
• elegant, partitionable, recomposable, resilient, …

• An implementation design is a guide towards future change

• evolvable, …
 Less of a Shared
Understanding
• An implementation design is a road map
• understandable, unambiguous, consistent, helpful, …

• An implementation design describes a path from

application / interaction / architecture design to the product
• correct, complete, concise, verifiable, effective, …

• An implementation design describes what the implementers

should do
• elegant, partitionable, recomposable, resilient, …

• An implementation design is a guide towards future change

• evolvable, …
 39

Designs Rated Highly By Peers

• 24

• 4

• 25

• 16

• 13
 Reflection

• What now is a good design?

• What now is a bad design?

• Have your perceptions of these changed through this

assignment?
• How do you know that your design does/does not hold
up well in the face of change?
• What kinds of changes do they hold up well/not so well
to?
• Design change examples in the evaluation form
 Reflection: What is the best
way to…
• Represent a graph?
• scatterplot
• bar graph
• pie chart?

• Represent the data?

• scatterplot
• bar graph
• pie chart?
• does a data point need to have its own class? Or can it be
a generic list/pairs?
 Reflection: What is the best
way to…
• Create the overall flow of the program?

• Get input from the user?

• Represent the logic that generates the graph?

• Where is this all done? In one spot? Different
classes?
 Next Time

• More patterns (finishing up design patterns

series)!