Software Design Patterns

Lecture 1
 Contents
● What is a Design Pattern?
● Elements of the Design Pattern
● What design patterns are NOT
● Describing Design Patterns
● Types of Design Patterns
● When to use Design Patterns
● Benefits of Design Patterns
● Draw backs to Design Patterns
● How to Select a Design Pattern
 What is a Design Pattern?

● “Design Pattern is a solution to a recurring design problem”.

● “Design patterns represent solutions to problems that arise

when developing software within a particular context”.

● “A design pattern is general reusable solution to a

commonly occurring problem in Software Design”. A
design pattern is not a finished design that can be
transformed directly into code.
“ Each pattern describes a problem which occurs
over and over again in our environment and then
describes the core of the solution to that problem,
in such a way that you can use this solution a
million times over, without ever doing it in the
same way twice ”

● Christopher Alexander, A Pattern Language, 1977

● Context: City Planning and Building architectures
 What is a Design Pattern?

● Patterns capture the static and dynamic structure

and collaboration among key participants in
software designs

● Especially good for resolving non-functional issues

● Patterns facilitate reuse of successful software

architectures and designs.
 What Makes it a Pattern?

● A Pattern must:
○ Solve a problem and be useful
○ Have a context and can describe where the solution can be
used
○ Recur in relevant situations
○ Provide sufficient understanding to tailor the solution
○ Have a name and be referenced consistently
 Elements of Design Patterns

● Design patterns have four essential elements:

○ Pattern name
○ Problem
○ Solution
○ Consequences
 Pattern Name

● A handle used to describe:

○ a design problem
○ its solutions
○ its consequences in a word or two

● Increases design vocabulary

● Makes it possible for us to think of design solution
at a higher level of abstraction
● Enhances communication
● “The Hardest part of programming is coming up with good variable
[function, and type] names.”
 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
 Design Patterns are NOT

● They are Not:

○ Designs that can be encoded in classes and reused as it
is (i.e., linked lists, hash tables)
○ Complex domain-specific designs (for an entire
application or subsystem)

● They are:
○ “Descriptions of communicating objects and classes that
are customized to solve a general design problem in a
particular context.”
 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
context of usage
 Design Pattern Descriptions

● Name and Classification: Essence of pattern

● Intent: What it does, its rationale, its context
● Also Known As: 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
 Types of Patterns

● Creational patterns:
○ Deal with creating, initializing, and configuring classes
and objects
● Structural patterns:
○ Deal Composition of classes or objects
○ Implementation of Interfaces, classes and objects.

● Behavioural patterns:
○ Behavioural patterns characterize the ways in which
classes or objects interact.
○ How they distribute responsibility
 Creational Patterns

● Abstract Factory:
○ Provide an interface for building related or dependant objects
without specifying their concrete class.
● Builder:
○ Separate the construction of a complex object from its
representation so that same construction process can create
different representations.
● Factory Method:
○ Define an interface for creating an object, but let subclass decide
which class to instantiate. Factory Method lets a class defer
instantiation to subclass.
 Creational Patterns (cont.)

● Prototype:
○ Specify the kinds of objects to create using a prototypical instance,
and create new objects by copying this prototype.
● Singleton:
○ Ensure a class only has one instance, and provide a global point of
access to it.
 Structural Patterns
● Adapter:
○ Convert the interface of a class into another interface that clients
expect. Adapter lets classes work together that couldn’t otherwise
because of the incompatible interfaces.
● Bridge:
○ Decouple an abstraction from its implementation so that the two
can vary independently.
● Composite:
○ Compose objects into tree structures to represent part-whole
hierarchies. Composite lets client treat individual objects and
compositions of objects uniformly.
● Decorator:
○ Attach additional responsibilities to an object dynamically.
Decorators provide a higher-level interface that makes the
subsystem easier to use.
 Structural Patterns (cont.)
● Facade:
○ Simplifies the interface for a subsystem

● Flyweight:
○ Many fine-grained objects shared efficiently.

● Proxy:
○ Provide a placeholder for another object to control access to it.
 Behavioural Patterns

● Chain of Responsibility:
○ Request delegated to the responsible service provider
● Command:
○ Encapsulate a request as an object, thereby letting you
parameterize clients with different requests, queue or log requests,
and support undoable operations.
● Iterator:
○ Provide a way to access the elements of an aggregate object
sequentially without exposing its underlying representation.
● 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 behaviour depends on its state

● Strategy:
○ Abstraction for selecting one of many algorithms

● Template Method:
○ Algorithm with some steps supplied by a derived class

● Visitor:
○ Represent an operation to be performed on the elements of an
object structure. Visitor lets you define a new operation without
changing the classes of the elements on which it operates.
 Design Pattern Space
Purpose
Creational Structural Behavioral
Scope Class Factory method Adapter (class) Interpreter
Template method
Object Abstract factory Adapter (object) Chain of
Builder Bridge responsibility
Prototype Composite Command
Singleton Decorator Iterator
Façade Mediator
Flyweight Memento
Proxy Observer
State
Strategy
Visitor
 Categorization Terms

● Scope is the domain over which a pattern applies

○ Class Scope: relationships between base classes and their
subclasses (static semantics)
○ Object Scope: relationships between peer objects

● Some patterns apply to both scopes.

 Class Scope

● Class:: Creational
○ Abstracts how classes are instantiated

○ Hides specifics of the creation process

● Class:: Structural
○ Use inheritance and composition for structural changes
and collaboration
● Class:: Behavioural
○ Captures how classes cooperate with each other to
share responsibilities.
 Object Scope

● Object:: Creational
○ Abstracts how sets of objects are created
● Object:: Structural
○ Describe ways to assemble objects to realize new
functionality
○ Achieved through polymorphism
○ Not possible with static class composition
● Object:: Behavioural
○ Describes how a group of peer objects cooperate to
perform a task that can be carried out by itself.
 When to Use Patterns

● Solutions to problems that recur with variations

○ No need for reuse if problem only arises in one context

● Solutions that require several steps:

○ Not all problems need all steps
○ Patterns can be an overload if solution is a simple linear set of
instructions
● Solutions where the solver is more interested in the
existence of the solution than its complete derivation
○ Patterns leave out too much to be useful to someone who really
wants to understand
 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
 Drawbacks to Design Patterns

● Patterns do not lead to direct code reuse

● Patterns are deceptively simple
● Teams may suffer from pattern overload
● Patterns are validated by experience and discussion
rather than by automated testing
● Integrating patterns into a software development
process is a human-intensive activity.
 How to Select a Design Pattern

● Consider how design pattern solve design

problems.
● Scan intent sections.
● Study how patterns interrelate.
● Study pattern’s purpose, similarities and contrasts.
● Examine cause of redesign
● Consider what should be variable in your design
 References

● Gama, Helm, Johnson, Vlissides, Design Patterns

Elements of Reusable Object-Oriented Software,
Addison Wesley, 1995

● B. Cheng – Michigan State University