Introduction to Design Patterns
Part 1
Patterns - Architectural
Architectural Patterns:
Related to large-scale and coarse-grained design;
Typically applied during the early iterations (the
elaboration phase) when the major structures and
connections are established.
Examples: pipe and filter; MVC; Client-Server;
Transaction, Broker, others…
© Lethbridge/Laganière 2001
Chapter 6: Using design patterns
2
Patterns – Design
Design Patterns:
Related to the small and medium-scale design of
objects and frameworks.
Applicable to designing a solution for connecting
the large scale elements defined via architectural
patterns
Done during detailed design work after architectural
design is ‘solid.’
Design patterns are sometimes known as
architectural patterns.
Chapter 6: Using design patterns
© Lethbridge/Laganière 2001
3
General Concepts of Design Patterns
Design Patterns are groups of objects (and their
relationships) designed to support a ‘good object design’
What is ‘good object design?’
design that yields high cohesion of our objects,
design that has low coupling between our objects,
which, among other things, fosters more likely reuse
It is one thing to create an object…it is quite another to
create the right object for the right situation.
© Lethbridge/Laganière 2001
Chapter 6: Using design patterns
4
Object Design – Not a Simple Undertaking!
All design involves making decisions, and design is a decision-making
activity
Good object design involves the assignment of object responsibilities.
There are patterns or groupings of objects that work together to
accommodate commonly needed activities / functions that subscribe to
accepted principles of good design.
Deciding what methods belong where and how objects interact (their
relationships) is critically important and NOT trivial.
All this is really at the heart of what it means to develop an objectoriented system, not merely the drawing of domain model diagrams,
package diagrams, etc.
© Lethbridge/Laganière 2001
Chapter 6: Using design patterns
5
Preview: What Design Patterns are All About
• Want to look at more class diagrams – static.
• But we want to look at recurring groupings of classes that are
regularly used to address common problems.
• Want to take advantage of experiences of others and create a better,
more resilient design.
• Want to use (note the categories of common problems)
Patterns that assist us in separating concerns (abstractionoccurrence, observer, player-role);
Patterns used to better create class hierarchies of instances;
Patterns in which one method simply calls another method
in another class (have you seen this??);
Patterns where you use delegation to gain access to facilities
in one or more other classes (Adaptor, Façade,
Proxy patterns);
Patterns that help protect other objects from unanticipated access
(immutable and read-only interfaces).
© Lethbridge/Laganière 2001
Chapter 6: Using design patterns
6
What Design Patterns are All About
The recurring aspects of designs are called design patterns.
•  A pattern is the outline of a reusable solution to a general
problem encountered in a particular context
• Many of them have been systematically documented for all software
developers to use
• A good pattern should
—Be as general as possible
—Contain a solution that has been proven to effectively solve
the problem in the indicated context.
Studying patterns is an effective way to learn from the experience of
others
We will look at several.
© Lethbridge/Laganière 2001
Chapter 6: Using design patterns
7
Pattern Description Parameters
Context:
• The general situation in which the pattern applies
Problem:
—A short sentence or two raising the main difficulty.
Forces:
• The issues or concerns to consider when solving the problem
Solution:
• The recommended way to solve the problem in the given context.
—‘to balance the forces’
Antipatterns: (Optional)
• Solutions that are inferior or do not work in this context.
Related patterns: (Optional)
• Patterns that are similar to this pattern.
References:
• Who developed or inspired the pattern.
© Lethbridge/Laganière 2001
Chapter 6: Using design patterns
8
Pattern Context
Remember: our patterns define a relation among:
a certain context
a problem
a solution
• Here again, naming a pattern is using an abstraction of the details of
that pattern
• Patterns represent well-known knowledge
• Really documents common practice
• Patterns should be in the public domain
• Patterns need to be written for the public good.
• We are looking at certain arrangements of classes and
relationships among classes that provide better design and/or
more flexibility in addressing common design issues
© Lethbridge/Laganière 2001
Chapter 6: Using design patterns
9
Pattern Names
Patterns have names and the names are ‘suggestive’ of what function they
address.
Their names can be used in our vocabulary to ‘communicate design
intentions.’
The Façade Pattern, can be used to provide the interface from one
layer to the next…
Singleton Pattern – to ensure global access to a single instance of a
class. (a class (really object!) that many processes may desire
access to: a monitor?)
More Design Patterns:
Information Expert (Expert); Adaptor, Creator, Observer,
Low Coupling, High Cohesion, Controller; etc. etc.
Design Patterns are often organized into different categories too.
(Most of these notes from the first two lectures on Design Patterns are taken directly
from Larman’s text.)
© Lethbridge/Laganière 2001
Chapter 6: Using design patterns
10
Categories of Design Patterns
We will study several of the most often used patterns –
GRASP Patterns, and
Gang of Four (GoF) Patterns
Others too.
You will note you may be already doing some of these things.
You may now see more rationale and more formal reasoning
In all cases, the patterns will be most helpful as we strive to
design objects and groupings of objects to accommodate
common issues.
© Lethbridge/Laganière 2001
Chapter 6: Using design patterns
11
We will look at:
Gang of Four (GoF) Patterns
Grasp Patterns
Others.
Here are some (not in any particular order):
1. Abstract-Occurrence
2. Singleton(GofF)
3. Observer(GofF)
4. Delegation
5. Adapter(GofF)
6. Façade (GofF)
7. Proxy(GofF)
8. Information Expert (Expert) (Grasp Pattern)
9. Creator (Grasp Pattern)
10. Controller Pattern (Grasp Pattern)
© Lethbridge/Laganière 2001
Chapter 6: Using design patterns
12