Mô hình thiết kế doc

DESIGN PATTERNS
EFA-EMS: Le Thi Thuy
INTRODUCTION
1
Content
I. What is a Design Pattern?
II. Three categories of Design Pattern
2.1. List of Design Patterns
2.2. Design Pattern Space
2.3. Relation among Design Patterns
III. Present common Design Patterns
3.1. Creational Patterns
3.2. Structural Patterns
3.3. Behavioral Pattern
IV. Referent
2
I.What is a Design Pattern(1)

Design patterns have their roots in the work of
Christopher Alexander (a civil engineer who wrote
about his experience in solving design issues as they
related to buildings &towns)

Software professionals began to incorporate
Alexander's principles into the creation of early
design pattern documentation as a guide to
novice developers.
3
I. What is a Design Pattern(2)

"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 the same way
twice” – Chirstopher Alexander

“Description of communicating objects and classes
that are customized to solve a general design
problem in a particular context” - Erich Gamma,
Richard Helm, Ralph Johnson, John Vlissides.

Each pattern focuses in a particular object-oriented
design problem or issue.
4
II. Three categories of Design Pattern

Creational patterns: are ones that create objects for
you, rather than having you instantiate objects
directly. This gives your program more flexibility in
deciding which objects need to be created for a
given case.

Structural patterns: help you compose groups of
objects into larger structures, such as complex user
interfaces or accounting data.

Behavioral patterns: help you define the
communication between objects in your system and
how the flow is controlled in a complex program.
5

2.1. List of Design Patterns

Creational Patterns
•
Abstract Factory
•
Builder
•
Factory Method
•
Prototype
•
Singleton

Structural Patterns
•
Adapter
•
Bridge
•
Composite
•
Decorator
•
Facade
•
Flyweight
•
Proxy


Behavioral Patterns
–
Chain of Responsibility
–
Command
–
Interpreter
–
Iterator
–
Mediator
–
Memento
–
Observer
–
State
–
Strategy
–
Template Method
–
Visitor
6
Purpose
Creational Structural Behavioral
Scope Class Factory Method Adapter (class) Interpreter
Template Method
Object Abstract Factory
Builder

Prototype
Singleton
Adapter (object)
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
Chain of Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor
Defer object creation to
another class
Defer object creation to
another object
Describe algorithms and
flow control
Describe ways to
assemble objects
2.2.Design Pattern Space
7
2.3. Relations among Design Patterns
Builder

Proxy
saving state
of iteration
c
r
e
a
t
i
n
g
c
o
m
p
o
s
i
t
e
s
Memento
Adapter
Bridge
Command
Iterator
A
v
o
i

d
i
n
g
h
y
s
t
e
r
e
s
i
s
Composite
Decorator
Enumerating
children
adding
responsibilities
to objects
composed
using
sharing
composites
Flyweight
defining
grammar
Interpreter
Visitor

a
d
d
i
n
g
o
p
e
r
a
t
i
o
n
s
d
e
f
i
n
i
n
g
t
r
a
v
e
r

s
a
l
s
d
e
f
i
n
i
n
g
t
h
e

c
h
a
i
n
Chain of
Responsibility
s
h
a
r
i
n
g

s
t
r
a
t
e
g
i
e
s
changing skin
versus guts
Strategy
a
d
d
i
n
g
o
p
e
r
a
t
i
o
n
s
State

sharing
strategies
s
h
a
r
i
n
g
t
e
r
m
i
n
a
l
s
y
m
b
o
l
s
Mediator Observer
co
m
p
l
e

x
d
e
p
e
n
d
e
n
c
y
m
a
n
a
g
e
m
e
n
t
Template Method
defining
algorithm´s
steps
Prototype
Abstract Factory
Singleton
Facade
Factory Method

i
m
p
l
e
m
e
n
t

u
s
i
n
g
single
instance
single
instance
c
o
n
f
i
g
u
r
e

f

a
c
t
o
r
y
d
y
n
a
m
i
c
a
l
l
y
often
uses
8
III. Present common Design Patterns

Creational Patterns
•
Abstract Factory
•
Builder
•
Factory Method
•

Singleton

Structural Patterns
•
Adapter
•
Decorator

Behavioral Patterns
–
Command
–
Observer
–
Strategy
9
3.1. Creational: Abstract Factory (1)
>
Intent:
Packing a group of classes that have a role as a Factory in
application. This is the class used to create objects. The factory
of this class has common programming interface is inherited
from parent class pure virtual (Virtual manufacturing).
>
Applicability
•
A system should be independent of how its products are created,
composed, and represented.
•
A system should be configured with one of multiple families of

products.
•
A family of related product objects is designed to be used
together, and you need to enforce this constraint.
•
You want to provide a class library of products, and you want to
reveal just their interfaces, not their implementations.
10
3.1.Creational: Abstract Factory (2)
11
AbtractFactory
Declares interface for operations
that create abstract product objects
ConcreteFactory
Implements operations to create
concrete product objects
AbstractProduct
Declares an interface for a
type of product object
ConcreteProduct
-
Defines a product object to be
created by concrete factory
-
Implements the abstract product
interface
Client
Uses only interfaces declared by
AbstractFactory and AbstractProduct
classes

3.1.Creational: BUILDER (1)
>
Intent:
•
Separate the construction of a complex object from its
representation so that the same construction process can create
different representations
>
Applicability
•
The algorithm for creating a complex object should be
independent of the parts that make up the object and how
they're assembled.
•
The construction process must allow different representations
for the object that's constructed.
12
3.1.Creational: BUILDER (2)

Builder
Abstract interface for creating objects
(product).

Concrete Builder
Provides implementation for Builder. It is an
object able to construct other objects.
Constructs and assembles parts to build the
objects

Director

The Director class is responsible for managing
the correct sequence of object creation. It
receives a Concrete Builder as a parameter
and executes the necessary operations on it.

Product
The final object that will be created by the
Director using Builder
13
3.1.Creational: FACTORY METHOD (1)
>
Intent:
•
Define an interface for creating an object, but let subclasses
decide which class to instantiate.
•
Factory Method lets a class defer instantiation to subclasses.
>
Applicability:
•
A class can´t anticipate the class of objects it must create.
•
A class wants its subclasses to specify the objects it creates.
•
Classes delegate responsibility to one of several helper
subclasses, and you want to localize the knowledge of which
helper subclass is the delegate.
14
3.1.Creational: FACTORY METHOD (2)
>

Product
•
Defines the interface of objects the
factory method creates.
>
ConcreteProduct
•
Implements the Product interface.
>
Creator
•
Declares the factory method, which
returns an object of type Product. Creator
may also define a default implementation
of the factory method that returns a
default ConcreteProduct object.
•
May call the factory method to create a
Product object.
>
ConcreteCreator
•
Overrides the factory method to return an
instance of a ConcreteProduct.
15
3.1.Creational: SINGELTON (1)
>
Intent: Ensure a class only has one instance, and provide a
global point of access to it.
>

Applicability
•
There must be exactly one instance of a class, and it must be
accessible to clients from a well-known access point.
•
When the sole instance should be extensible by sub classing,
and clients should be able to use an extended instance
without modifying their code.
16
3.1.Creational: SINGLETON (2)
Singleton
Defines an Instance operation
that lets clients access its
unique instance. Instance is a
class operation may be
responsible for creating its own
unique instance.
17
3.2.Structural: ADAPTER PATTERN (1)
>
Intent:
•
Create an interface to play an intermediary role
>
Motivation:
•
Sometimes a toolkit class that's designed for reuse isn't reusable only
because its interface doesn't match the domain-specific interface an
application requires.
>

Applicability:
•
You want to use an existing class, and its interface does not match
the one you need.
•
You want to create a reusable class that cooperates with unrelated or
unforeseen classes, that is, classes that don't necessarily have
compatible interfaces.
•
(object adapter only) You need to use several existing subclasses, but
it's impractical to adapt their interface by sub classing every one. An
object adapter can adapt the interface of its parent class.
18
3.2. Structural: ADAPTER PATTERN (2)
Target
Defines the domain-specific interface that
Client uses.
Client
Collaborates with objects conforming to the
Target interface.
Adaptee
Defines an existing interface that needs
adapting.
Adapter
Adapts the interface of Adaptee to the Target
interface.
19
3.2. Structural: DECORATOR (1)
>
Intent:

Attach additional responsibilities to an object dynamically.
Decorators provide a flexible alternative to sub classing for
extending functionality.
>
Applicability
•
To add responsibilities to individual objects dynamically and
transparently, that is, without affecting other objects.
•
For responsibilities that can be withdrawn.
•
When extension by subclassing is impractical. Sometimes a
large number of independent extensions are possible and
would produce an explosion of subclasses to support every
combination. O r a class definition may be hidden or otherwise
unavailable for subclassing.
20
3.2. Structural: DECORATOR (2)
Component
Defines the interface for objects
that can have responsibilities
added to them dynamically.
ConcreteComponent
Defines an object to which
additional responsibilities can be
attached.
Decorator
Maintains a reference to a
Component object and defines an
interface that conforms to

Component's interface.
ConcreteDecorator
Adds responsibilities to the
component.
21
3.3.Behavioral: Command(1)
>
Intent
•
Encapsulate a request as an object, thereby letting you
parameterize clients with different requests, queue or log
requests, and support undoable operations.
>
Applicability
• Parameterize objects by an action to perform
• Specify, queue and execute requests at different times
• Support undo
• Support logging changes that can be reapplied after a crash
• Structure a system around high-level operations built out of
primitives
22
3.3.Behavioral: Command(2)
Command
Declares an interface for executing an
operation.
ConcreteCommand
Defines a binding between a Receiver
object and an action.
Implements Execute by invoking the
corresponding operation(s) on

Receiver.
Invoker
Asks the command to carry out the
request.
Receiver
Knows how to perform the operations
associated with carrying out a
request. Any class may serve as a
Receiver.
23
3.3.Behavioral: Observer(1)
>
Intent
Define a one-to-many dependency between objects so that
when one object changes state, all its dependents are notified
and updated automatically.
>
Applicability
• When an abstraction has two aspects, one dependent on the
other, and you want to reuse each
• When change to one object requires changing others, and you
don’t know how many objects need to be changed
• When an object should be able to notify others without
knowing who they are
24
3.3.Behavioral: Oberver(2)
Subject
•
Knows its observers. Any number of
Observer objects may observe a

subject.
•
Provides an interface for attaching
and detaching Observer objects.
Observer
Defines an updating interface for
objects that should be notified of
changes in a subject.
ConcreteSubject
•
Stores state of interest to Concrete
Observer objects.
•
Sends a notification to its observers
when its state changes.
25