Design Patterns
Alan Shalloway, James Trott, Design Patterns
Explained, Addison-Wesley, 2002.
Gamma, Helm, Johnson, Vlissides, Design
Patterns, Elements of Reusable Object-Oriented
Software, Addison-Wesley, 1995.
Perspectives in software
development:
• Conceptual: represent concepts. Ignore
how software implements it. (SRS)
• Specification: look at the software
interfaces, not at the implementation
• Implementation: write code
Design Pattern
• Describes
– problem that occurs repeatedly
– the core of the solution to that problem
• Solution can be reused
– not necessary to implement it the same way
Where do you see Design
Patterns?
• Seminars and conferences.
• Technical journals.
• Text books and trade journals.
• You don’t really know OO until you
understand these.
• They may help you understand OO better.
Where did they come from?
Patterns start with a premise and answer two
questions:
– Premise: the goodness of a design is objective:
not entirely in the eyes of the beholder.
– Q1: What is present in good designs that is not
present in poor ones?
– Q2: What is present in poor designs that is not
present in good ones?
Pattern: A solution to a problem
in a context
• Name
– Becomes part of our vocabulary
– Allows abstract discussion of problem and approaches
– Allows discussion of issues instead of implementation
• Purpose
– Description of the desirable thing
– Problems that prevent the desirable solution explicitly
described
Vocabulary Example: find
number in sorted list
• Find middle value and compare value we
are looking for to that one. If found, we’re
done. Otherwise, if we are looking for
something bigger, set the new bottom to the
current middle. Otherwise, set the new top
to the current middle.
• Repeat the above step until the list can’t be
divided further. If it’s not in the last two
positions, it’s not in the list.
Example 2: find number in sorted
list
• Use binary search.
Example 2: find number in sorted
list
• Use binary search.
• This assumes that you know what binary
search is.
• But if you know what binary search is, the
discussion is greatly simplified.
• Algorithms are not patterns. This is an
analogy.
Description of patterns:
•
•
•
•
•
•
•
•
Name
Intent
Problem
Solution
Participants
Consequences
Implementation
References
how does the pattern solve the problem
investigate forces at play
Note: this is not the pattern itself.
(GoF?)
Elements
• Pattern name
• Problem
– Explains the problem and its context
– may include a list of conditions needed before
application of solution makes sense
• Solution
• Consequences
Elements
• Pattern name
• Problem
• Solution
– Describes elements of design, relationships,
responsibilities, and collaborations
– Does not describe a particular implementation
– Abstract description and how a general arrangements of
objects solves problem
• Consequences
Elements
•
•
•
•
Pattern name
Problem
Solution
Consequences
– Results and trade-offs of applying pattern
– Needed to evaluate tradeoffs between solutions
– Frequently time/space trade-offs
Why patterns?
• Reuse existing, high-quality
solutions to common problems
– incorporates a great deal of
experience
– may describe things often
overlooked or subtle that prevent
good solutions
Why patterns?
• Reuse existing, high-quality solutions to common
problems
– incorporates a great deal of experience
– may describe things often overlooked or subtle that
prevent good solutions
• Focus on issues not implementation
–
–
–
–
Shift thinking to higher level
Decide if design is right, not just working
Learn how to design
Improve code: smaller hierarchies, more modifiable
code.
Strategies suggested by patterns
1. Design to interfaces
Strategies suggested by patterns
1. Design to interfaces
2. Favor composition over inheritance
Strategies suggested by patterns
1. Design to interfaces
2. Favor composition over inheritance
3. Find what varies and encapsulate it.
• Consider what should vary in your design.
• Consider what you want to be able to change
without redesign (as opposed to what might
force you to redesign)
• Encapsulate this
Catalog of Patterns
• GOF = “Gang of four” (1995)
–
–
–
–
Erich Gamma
Richard Helm
Ralph Johnson
John Vlissides
• 23 patterns
• Others since then
GOF: 23 Patterns
•
•
•
•
•
Abstract Factory
Adapter
Bridge
Builder
Chain of
Responsibility
• Command
• Composite
•
•
•
•
•
•
•
•
Decorator
Facade
Factory Method
Flyweight
Interpreter
Iterator
Mediator
Memento
•
•
•
•
•
•
•
Observer
Prototype
Proxy
Singleton
State
Strategy
Template
Method
• Visitor
Design Pattern Classification
• We classify design patterns by two
criteria:
– Purpose: Reflects what the Pattern does.
– Scope: Specifies whether the pattern
applies primarily to classes or to objects.
Design Pattern Purposes
• Patterns can have either creational,
structural, or behavioral purpose.
– Creational patterns: concern the process of
object creation.
– Structural patterns: deal with the composition
of classes or objects.
– Behavioral patterns: characterize the ways in
which classes or objects interact and distribute
responsibility.
Design Patterns Scopes
• Class patterns deal with relationships
between classes and their subclasses.
– These relationships are established through
inheritance, so they are static—fixed at
compile-time.
• Object patterns deal with object
relationships, which can be changed at runtime and are more dynamic.
In General
• Almost all patterns use inheritance to some
extent.
• The only patterns labeled "class patterns"
are those that focus on class relationships.
• Note that most patterns are in the Object
scope.
Solving Problems
• Patterns help you identify non-obvious
abstractions
– e. g. Strategy describes pattern for
interchangeable families of algorithms
• Patterns can guide decisions about what is
an object
How to Select a Design Pattern
• Consider how design patterns solve design
problems
• Scan Intent sections
• Study how patterns interrelate and patterns
of like purpose
• Consider what should be variable in your
design
How to use a pattern
• Read the pattern paying attention to Applicability
and Consequences
• Study the Structure, Participants, and
Collaborations
• Look at Sample Code
• Choose good names for participants
• Define the classes, interfaces, and operations
• Implement the operations to carry out the
responsibilities and collaborations
GOF Design Patterns App
• Android for $.99
• Take a look at it… might be helpful for
exam and/or project
Design Patterns:
Model-View Separation
Motivation:
• Suppose you have a system that needs to
run on a variety of devices
– Maybe a cell phone and a PDA
– Maybe Windows and with a command line
–...
Motivation:
• Suppose we support both the command line
and the GUI interfaces.
• What changes?
• What stays the same?
Motivation:
• Suppose we support both the command line
and the GUI interfaces.
• What changes?
• What stays the same?
• How do you design to handle this?
Model-View Separation Pattern
• Model: The domain layer of objects.
(objects that contain data and operations).
• View: The presentation layer of objects
(windows, applets, reports).
Model-View Context
• Context/Problem
– It is desirable to:
• de-couple domain (model) objects from
windows (views)
• support increased reuse of domain objects
• minimize the impact of changes in the
interface upon domain objects
Model-View Context
• Context/Problem
It is desirable to de-couple domain (model) objects from
windows (views), to support increased reuse of domain
objects, and minimize the impact of changes in the
interface upon domain objects.
• Solution
Define the domain (model) classes so that they do not have
direct coupling or visibility into the window (view)
classes, and so that application data and functionality is
maintained in domain classes, not window classes.
Model-View
View
Window
display( )
Configuration
Model
addEntry( )
query( )
Goal: Classes
in Model should
not have direct
visibility to
classes in View.
Model-View Separation
Motivation
Motivation
• Focus more on the domain processes rather than
on computer interfaces.
• Allow separate development of the model and user
interface layers.
• Minimize the impact of changes in the interface
upon the domain layer.
• Allow new views to be easily connected to an
existing domain layer.
Problem
View
Window
display( )
Worse
Model classes
talk to View
classes.
displayMessage ( )
Configuration
Model
addEntry( )
query( )
Model-View Separation Pattern
View
Window
display( )
query( )
Configuration
Model
addEntry( )
query( )
Better
View classes
talk to Model
classes.
Model-View Separation Pattern
View
New Window
Old Window
display( )
display( )
query( )
Configuration
Model
addEntry( )
query( )
The View Layer
can be modified
without affecting
the Model layer.
Model-View Separation Pattern
View
New Window
display( )
query( )
Configuration
Model
addEntry( )
query( )
When the Window
needs to display
data it queries the
Model objects
“Polling Model”
Model-View Separation Pattern
• Problem: Domain objects need to
communicate with windows to cause a realtime ongoing display update as the state of
information in the domain object changes.
- Monitoring applications
- Simulation applications
• Solution: Indirect Visibility
Model-View Separation Pattern
with Indirect Visibility
• Named Publish-Subscribe Pattern
• Context/Problem:
A change in state (an event) occurs within a Publisher
of the event and other objects are dependant on or
interested in this event (Subscribers to the event).
The Publisher should not have direct knowledge of
its subscribers.
• Solution:
Define an event notification system so that the
Publisher an indirectly notify Subscribers. Event
Manager or Model View Controller (MVC).
Model-View Separation Pattern
with Indirect Visibility
http://gmoeck.github.com/2011/03/10/sproutcore-mvc-vs-rails-mvc.html
Model-View Separation Pattern
with Indirect Visibility
Design Patterns:
Façade
Façade
• Intent: want to simplify the use of an existing
system. Need to define an interface that is a subset
of the existing one.
• Problem:
– You only need a subset of a complex system or need to
interact in a particular way.
– The API for the subset is simpler than the API for the
entire subsystem.
– You may want to hide the original system, or you may
want to use a subset of the system and add
functionality.
Façade
• Solution: The façade presents a new interface
• Participants: presents a specialized interface to
the client to make it easier to use
• Consequences:
– Simplifies the use of the subsystem.
– Some functionality may not be available to the client.
• Implementation:
– Define a new class (or classes) that has the required
interface.
– Have this class use the existing system.
Façade Example
• Huge database interface, but we only need a
few of the functions.
• Rather than everyone learning the database
interface, create the interface you need, and
build a façade.
Without Façade
ClientA
Database
ClientB
Model
Element
With Façade
ClientA
Database
ClientB
DBFacade
Model
Element
Other Patterns of Interest
•
•
•
•
State Design Pattern
Strategy Design Pattern
Singleton Design Pattern
Adapter Design Pattern