DESIGN PATTERNS PRINCIPLES

Software Design Patterns

FAKHRELDIN ALI
[Link]@[Link]
OBJECTIVES

 Explain the purpose and the general form of design patterns.

 To learn the creational design patterns and when to use them.
 To learn the structural design patterns and when to use them.
 To learn the behavioral design patterns and when to use them.

DESIGN PATTERNS 2
TOPICS COVERED

 History of patterns
 Benefits of using patterns
 What are design patterns
 Types of design patterns:
 Creational, structural, and behavioral
 Characteristics of design patterns
 Viewpoints, roles, and levels

DESIGN PATTERNS 3
HISTORY OF PATTERNS

 the concept of a "pattern" was first expressed

in Christopher Alexander's work A Pattern
Language in 1977 (2543 patterns)

 in 1990 a group called the Gang of Four or "GoF"

(Gamma, Helm, Johnson,Vlissides) compile a
catalog of design patterns

 1995 book Design Patterns:

Elements of Reusable Object-Oriented
Software is a classic of the field

DESIGN PATTERNS 4
BENEFITS OF USING PATTERNS

 patterns are a common design vocabulary

 allows engineers to abstract a problem and talk about that abstraction in isolation from
its implementation
 embodies a culture; domain-specific patterns increase design speed

 patterns capture design expertise and allow that expertise to be communicated

 promotes design reuse and avoid mistakes

 improve documentation (less is needed) and understandability (patterns are

described well once)
DESIGN PATTERNS 5
SAMPLE DESIGN GOALS AND WAYS TO
ACCOMPLISH THEM

 Reusability, Flexibility, and Maintainability

 Reuse flexible designs
 Keep code at a general level
 Minimize dependency on other classes
 Robustness
 Reuse reliable designs
 Reuse robust parts
 Sufficiency / Correctness
 Modularize design
 Reuse trusted parts

DESIGN PATTERNS 6
DESIGN PATTERNS: APPLICATIONS

 Wide variety of application domains:

 drawing editors, banking, cellular network management, telecom switches, program
visualization
 Wide variety of technical areas:
 user interface, communications, persistent objects, O/S kernels, distributed systems

DESIGN PATTERNS 7
WHAT ARE DESIGN PATTERNS?

 A design pattern is “a common solution to a common problem in a given

context.”
-Jacobson et al.

 Design patterns are class combinations and accompanying algorithms that fulfill
common design purposes
 Design pattern expresses an idea

DESIGN PATTERNS 8
WHAT IS A DESIGN PATTERN

A pattern has 4 essential elements:

• Pattern name
• Problem
• Solution
• Consequences

DESIGN PATTERNS 9
 PATTERN NAME

• A handle used to describe:

• a design problem,
• its solutions and
• its consequences

• Increases design vocabulary

• Makes it possible to design at a higher level of abstraction

• Enhances communication
DESIGN PATTERNS 10

But finding a good name is often difficult

PROBLEM

• Describes when to apply the pattern

• Explains the problem and its context
• Might describe specific design problems or class
or object structures
• May contain a list of conditions
• must be met
• before it makes sense to apply the pattern

DESIGN PATTERNS 11
 SOLUTION

• Describes the elements that make up the

• design,
• their relationships,
• responsibilities and
• collaborations
• Does not describe specific concrete
implementation
• Abstract description of design problems and
• how the pattern solves it
DESIGN PATTERNS 12
CONSEQUENCES

• Results and trade-offs of applying the pattern

• Critical for:
• evaluate design alternatives and
• understand costs and
• understand benefits of applying the pattern
• Includes the impacts of a pattern on a system’s:
• flexibility,
• extensibility
• portability
DESIGN PATTERNS 13
 DESIGN PATTERNS ARE NOT

• Designs that can be encoded in classes and reused as 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.”

DESIGN PATTERNS 14
 WHERE DESIGN PATTERNS
ARE USED

• Object-Oriented Programming Languages:

• more amenable to implementing design
patterns

• Procedural languages: need to define

• Inheritance,
• Polymorphism and
• Encapsulation
DESIGN PATTERNS 15
 HOW TO DESCRIBE DESIGN PATTERNS

• Graphical notation is not sufficient

• In order to reuse design decisions,

• alternatives and trade-offs that led to the
decisions are important
• Concrete examples are also important

DESIGN PATTERNS 16
WHY SHOULD I LEARN PATTERNS?

 Design patterns are a toolkit of tried and tested solutions to

common problems in software design. Even if you never
encounter these problems, knowing patterns is still useful because
it teaches you how to solve all sorts of problems using principles
of object-oriented design.
 Design patterns define a common language that you and your
teammates can use to communicate more efficiently. You can say,
“Oh, just use a Singleton for that,” and everyone will understand
the idea behind your suggestion. No need to explain what a
singleton is if you know the pattern and its name.
DESIGN PATTERNS 17
DESIGN PATTERNS BY TYPE

 Creational patterns: creating a collection of objects in flexible ways.

 Structural patterns: representing a collection of related objects.
 Behavioral patterns: capturing behavior among a collection of objects.

DESIGN PATTERNS 18
CREATIONAL DESIGN PATTERNS
Key Concept — Creational Design Patterns

Used to create objects in flexible or constrained ways.

DESIGN PATTERNS 19
STRUCTURAL DESIGN PATTERNS
Key Concept — Structural Design Patterns
Used to represent data structures such as trees, with
uniform processing interfaces.

DESIGN PATTERNS 20
BEHAVIORAL DESIGN PATTERNS
Key Concept — Behavioral Design Patterns

To capture behavior among objects.

DESIGN PATTERNS 21
CHARACTERISTICS OF DESIGN PATTERNS

 Viewpoints – ways to describe patterns

 Static: class model (building blocks)
 Dynamic: sequence or state diagram (operation)
 Levels – decomposition of patterns
 Abstract level describes the core of the pattern
 Concrete (= non abstract) level describes the particulars of this case
 Roles – the “players” in pattern usage
 Application of the design pattern itself
 Clients of the design pattern application
 Setup code initializes and controls

DESIGN PATTERNS 22
(class or classes)
1. Client role CHARACTERISTICS OF DESIGN
PATTERNS
3. Role: Application of the design pattern

A. Static viewpoint B. Dynamic viewpoint

A B (i) Abstract level

(ii) Concrete level

C D
(sequence or
(class model)
state diagram)

2. Setup role
DESIGN PATTERNS 23
: Reference direction
(class or classes)
CATEGORIZE DESIGN PATTERNS
Purpose

Creational Structural Behavioral

Scope Class Factory Method Adapter (class) Interpreter
Template Method
Object Abstract Factory Adapter (object) Chain of Responsibility
Builder Bridge Command
Composite Iterator
Prototype
Decorator Mediator
Singleton
Flyweight Memento
Observer
Facade
State
Proxy Strategy
Visitor

DESIGN PATTERNS 24
CATEGORIZATION TERMS

 Scope: domain over which a pattern applies

 Class Scope:
 relationships between base classes and their subclasses
 Static semantics

 Object Scope:
 relationships between peer objects
 Can be changed at runtime
 More dynamic

DESIGN PATTERNS 25
PURPOSE OF PATTERNS

 Creational:
 Class: defer some part of object creation to subclasses
 Object: Defer object creation to another object
 Structural:
 Class: use inheritance to compose classes
 Object: describe ways to assemble classes
 Behavioral:
 Class: use inheritance to describe algs and flow of control
 Object: describes how a group of objects cooperate to
perform task that no single object can complete
DESIGN PATTERNS 26
CREATIONAL PATTERNS

 Factory Method:
 method in a derived class creates associations, provides an interface for creating
objects in a superclass, but allows subclasses to alter the type of objects that
will be created.
 Abstract Factory:
 Factory for building related objects
 Builder:
 Factory for building complex objects incrementally
 Prototype:
 Factory for cloning new instances from a prototype
 Singleton:
 Factory for a singular (sole) instance

DESIGN PATTERNS 27
STRUCTURAL PATTERNS:

 Adapter:
 Facade:
 Translator adapts a server
interface for a client  simplifies the interface for a
 Bridge: subsystem
 Abstraction for binding one of
many implementations
 Flyweight:
 Composite:  many fine-grained objects
shared efficiently.
 Structure for building recursive
aggregations
 Proxy:
 Decorator:
 one object approximates
 Decorator extends an object
transparently another

DESIGN PATTERNS 28
 BEHAVIORAL PATTERNS

 Chain of Responsibility  Mediator:

 coordinates interactions
 request delegated to the between its associates
responsible service provider
 Memento:
 Command:
 snapshot captures and restores
 request is first-class object object states privately
 Iterator:  Observer:
 Aggregate elements are  dependents update
accessed sequentially automatically when subject
changes
 Interpreter:  State:
 language interpreter for a  object whose behavior depends
small grammar on its state
DESIGN PATTERNS 29
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 SW development
process is a human-intensive activity.
DESIGN PATTERNS 30
 SUGGESTIONS FOR EFFECTIVE PATTERN USE

 Do not recast everything as a pattern

 Instead, develop strategic domain patterns and reuse existing tactical
patterns
 Institutionalize rewards for developing patterns
 Directly involve pattern authors with application developers
and domain experts
 Clearly document when patterns apply and do not apply
 Manage expectations carefully.
DESIGN PATTERNS 31
SUMMARY

 Design Patterns are recurring designs satisfying recurring design purposes

 Described by Static and Dynamic Viewpoints
 Typically class models and sequence diagrams respectively
 Use of a pattern application is a Client Role
 Client interface carefully controlled
 “Setup,” typically initialization, a separate role
 Design patterns Forms usually Delegation or Recursion
 Classified as Creational, Structural, or Behavioral

DESIGN PATTERNS 32