Mô hình thiết kế doc

What is a Design Pattern2 "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

DESIGN PATTERNS

EFA-EMS: Le Thi Thuy

INTRODUCTION

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

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.

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.

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.

2.1 List of Design Patterns

– Interpreter – Iterator – Mediator

– Memento – Observer – State

– Strategy – Template Method – Visitor

Template Method

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

2.2.Design Pattern Space

2.3 Relations among Design Patterns

Composite Decorator

Enumerating children

adding responsibilities

to objects

composed using

sharing composites

Flyweight defininggrammar

Interpreter

Visitor

addingope rations

defining traversals

defining

Responsibility

sharingstrategies

changing skin versus guts

Strategy

addingoperations

State

sharing strategies

sharingterm inal sym bols

complex dependency management

Template Method

defining algorithm´s steps

single instance

configu re factory

III Present common Design Patterns

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)

• 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

3.1.Creational: Abstract Factory (2)

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.

The final object that will be created by the

Director using Builder

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.

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.

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.

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

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.

3.2 Structural: ADAPTER PATTERN (2)

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.

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.

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

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.

• When an object should be able to notify others without

knowing who they are

Defines an updating interface for

objects that should be notified of

3.3.Behavioral: Strategy(1)

> Intent

Define a family of algorithms, encapsulate each one, and make them interchangeable Strategy lets the algorithm vary independently from clients that use it.

> Applicability

• Many related classes differ only in their behavior Strategies provide a

way to configure a class with one of many behaviors.

• You need different variants of an algorithm.

• An algorithm uses data that clients shouldn't know about Use the

Strategy pattern to avoid exposing complex, algorithm-specific data structures.

• A class defines many behaviors, and these appear as multiple

conditional statements in its operations Instead of many conditionals, move related conditional branches into their own Strategy class.

3.3.Behavioral: Strategy(2)

Strategy

Declares an interface common to all

supported algorithms Context uses this interface to call the algorithm defined by a ConcreteStrategy.

• Maintains a reference to a Strategy object.

• May define an interface that lets Strategy access its data.

> “Design Patterns: Elements of Reusable Object-Oriented

Software” by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

> “Refactoring to Patterns” by Joshua Kerievsky-

http://www.industriallogic.com

> “Head First Design Patterns” by Eric Freeman & Elisabeth

Freeman with Kathy Sierra & Bert Bates

> “Object-Oriented Design Heuristics” by Arthur J Riel