Software Design Patterns

Background
• Search for recurring successful designs –
emergent designs from practice (via trial and
error)
• Supporting higher levels of reuse (i.e., reuse of
designs) is quite challenging
• Described in Gama, Helm, Johnson, Vlissides
1995 (i.e., “gang of 4 book”)
• Based on work by Christopher Alexander (an
Architect) on building homes, buildings and
towns.
 Background2
• Design patterns represent solutions to
problems that arise when developing
software within a particular context, e.g.,
problem/solution pairs within a given
context
• Describes recurring design structures
• Describes the context of usage
 Background3
• Patterns capture the static and dynamic
structure and collaboration among key
participants in software designs
• Especially good for describing how and
why to resolve nonfunctional issues
• Patterns facilitate reuse of successful
software architectures and designs.
 Elements of Design Patterns
• Design patterns have four essential
elements:
– Pattern name
– Problem
– Solution
– Consequences
 Pattern Name
• A handle used to describe:
“The Hardest part of
– a design problem programming is coming up
with good variable [function,
– its solutions and type] names.”
J. Maletic
– its consequences
• Increases design vocabulary
• Makes it possible to design at a higher
level of abstraction
• Enhances communication
 Problem
• Describes when to apply the pattern
• Explains the problem and its context
• May describe specific design problems
and/or object structures
• May contain a list of preconditions that
must be met before it makes sense to
apply the pattern
 Solution
• Describes the elements that make up the
– design
– relationships
– responsibilities
– collaborations
• Does not describe specific concrete
implementation
• Abstract description of design problems
and how the pattern solves it
 Consequences
• Results and trade-offs of applying the pattern
• Critical for:
– evaluating design alternatives
– understanding costs
– understanding benefits of applying the pattern
• Includes the impacts of a pattern on a system’s:
– flexibility
– extensibility
– portability
 Describing Design Patterns
• Graphical notation is generally not
sufficient
• In order to reuse design decisions the
alternatives and trade-offs that led to the
decisions are critical knowledge
• Concrete examples are also important
• The history of the why, when, and how set
the stage for the context of usage
 Design Patterns
• Describe a recurring design structure
– Defines a common vocabulary
– Abstracts from concrete designs
– Identifies classes, collaborations, and
responsibilities
– Describes applicability, trade-offs, and
consequences
 Example: Compiler
Compiler

+Compile()

lex Parser Code Generator

Token Symbol table

 Façade Pattern
• Intent
– Provide a unified interface to a set of
interfaces in a subsystem.
– Façade defines a higher-level interface that
makes the subsystem easier to use
 Structure
Facade

+interface()

Subsystem
 Design Pattern Descriptions
• Name and Classification: Essence of pattern
• Intent: What it does, its rationale, its context
• AKA: Other well-known names
• Motivation: Scenario illustrates a design problem
• Applicability: Situations where pattern can be applied
• Structure: Class and interaction diagrams
• Participants: Objects/classes and their responsibilities
• Collaborations: How participants collaborate
• Consequences: Trade-offs and results
• Implementation: Pitfalls, hints, techniques, etc.
• Sample Code
• Known Uses: Examples of pattern in real systems
• Related Patterns: Closely related patterns
 Example: Stock Quote Service
Real time
Market Data
Feed

Stock Quotes

Customer Customer

Customer Customer Customer

Observers
 Observer Pattern
• Intent:
– Define a one-to-many dependency between objects
so that when one object changes state, all its
dependents are notified and updated automatically
• Key forces:
– There may be many observers
– Each observer may react differently to the same
notification
– The subject should be as decoupled as possible from
the observers to allow observers to change
independently of the subject
 Structure of Observer Pattern
Subject Observer

for all observers obs +notify() * +update()

{
obs->update()
+attach(in Observer) 1

} +detach(in Observer)

ConcreteObserver
ConcreteSubject
-subjectSate * +update()
+getState() 1

return subjectState observerState = subject->getState()

Collaborations in Observer Pattern
S1 : ConcreteSubject obs1 : ConcreteObserver obs2 : ConcreteObserver

setState()

notify()

update()

getState()
update()

getState()
 Example: List and Itor
• Abstract list (array or linked structure)
• Separate interator that allows sequential
access to the list structure without
exposing the underlying representation
• Used in STL
• AKA: Cursor
 Iterator Pattern
Aggregate Client Iterator

+createIterator() +first()
+next()
+isDone()
+currentItem()

«instance»
ConcreteAggregate

itor : ConcreteIterator
+createIterator()

{
...
return new ConcreteIterator(this);
...
}
 Types of Patterns
• Creational patterns:
– Deal with initializing and configuring classes and
objects
• Structural patterns:
– Deal with decoupling interface and implementation of
classes and objects
– Composition of classes or objects
• Behavioral patterns:
– Deal with dynamic interactions among societies of
classes and objects
– How they distribute responsibility
 Creational Patterns
• Abstract Factory:
– Factory for building related objects
• Builder:
– Factory for building complex objects incrementally
• Factory Method:
– Method in a derived class creates associates
• Prototype:
– Factory for cloning new instances from a prototype
• Singleton:
– Factory for a singular (sole) instance
 Structural Patterns
• Adapter:
– Translator adapts a server interface for a client
• Bridge:
– Abstraction for binding one of many implementations
• Composite:
– Structure for building recursive aggregations
• Decorator:
– Decorator extends an object transparently
• Facade:
– Simplifies the interface for a subsystem
• Flyweight:
– Many fine-grained objects shared efficiently.
• Proxy:
– One object approximates another
 Behavioral Patterns
• Chain of Responsibility:
– Request delegated to the responsible service provider
• Command:
– Request is first-class object
• Iterator:
– Aggregate elements are accessed sequentially
• Interpreter:
– Language interpreter for a small grammar
• Mediator:
– Coordinates interactions between its associates
• Memento:
– Snapshot captures and restores object states privately
 Behavioral Patterns (cont.)
• Observer:
– Dependents update automatically when subject changes
• State:
– Object whose behavior depends on its state
• Strategy:
– Abstraction for selecting one of many algorithms
• Template Method:
– Algorithm with some steps supplied by a derived class
• Visitor:
– Operations applied to elements of a heterogeneous object
structure
 Class:: Creational
• Abstracts how objects are instantiated
• Hides specifics of the creation process
• May want to delay specifying a class name
explicitly when instantiating an object
• Just want a specific protocol
 Example
• Use Factory Method to instantiate members in base
classes with objects created by subclasses

• Abstract Application class: create application-specific

documents conforming to a particular Document type
• Application instantiates these Document objects by
calling the factory method CreateDocument
• Method is overridden in classes derived from Application
• Subclass DrawApplication overrides CreateDocument to
return a DrawDocument object
 Factory Method Pattern

Creator
Product {
product=FactoryMethod()
+FactoryMethod()
}
+Operation1()

ConcreteProduct «instance» ConcreteCreator {

Return new ConcreteProduct()
}
+FactoryMethod()
 Class:: Structural
• Use inheritance to compose protocols or code
• Example:
– Adapter Pattern: makes one interface (Adaptee’s)
conform to another
– Gives a uniform abstraction of different interfaces
– Class Adapter inherits privately from an Adaptee
class
– Adapter then expresses its interface in terms of the
Adaptee’s.
 Adapter Pattern

Client target adaptee

+request() +specificRequest()

adapter {
specificRequest();
}
+request()
 Benefits of Design Patterns
• Design patterns enable large-scale reuse of
software architectures and also help document
systems
• Patterns explicitly capture expert knowledge and
design tradeoffs and make it more widely
available
• Patterns help improve developer communication
• Pattern names form a common vocabulary
• Patterns help ease the transition to OO
technology