LectureConclusionpdf

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (433.36 KB, 19 trang )

(1)<div class='page_container' data-page=1>

Conclusions

CSIE Department, NTUT

Woei-Kae Chen

Discussion of Behavior Patterns

z

Encapsulating Variation (with inheritance; p345)

–

encapsulate an aspect that

changes frequently

znew object: encapsulates the aspect

zexisting object: use the new object

–

Example

zStrategy Ỉalgorithm

zState Ỉstate-dependent behavior
zIterator Ỉtraversal

zAbstract Factory, Builder Ỉobject creation
zCommand Ỉcommand

zVisitor Ỉoperation

–

Advantage

znew objects can be changed at run-time
zvary new and existing objects independently
zeasy to add new objects

zeasy to maintain and reuse

–

Disadvantage

zhave to open interfaces for new objects to access existing objects

</div>
(2)<div class='page_container' data-page=2>

Discussion of Behavior Patterns

z

Encapsulating Variation (without inheritance)

–

define an

object

to encapsulate an aspect that

changes

frequently

znew object: encapsulates the aspect
zexisting object: use the new object

–

Example

zMediator encapsulates the protocol between objects
zPrototype encapsulates object creation

zDecorator encapsulates responsibility added to an object
zBridge encapsulates an abstraction from its implementation

Discussion of Behavior Patterns

z

Object as arguments

–

Visitor

zis the argument to the

accept

operation

–

Command

zact as tokens to be passed around and invoked later

zthe token represents a request

–

Memento

</div>
(3)<div class='page_container' data-page=3>

Discussion of Behavior Patterns

z

Should communication be encapsulated or distributed?

–

Mediator Ù

Observer

zcompeting patterns

–

Mediator

zencapsulates communication between objects
zcentralizes communications

zmaintains a communication constraint in the mediator
zdifficult to make reusable Mediators

zeasier to understand the flow of communication

–

Observer

zdistributes communication by introducing Observer and Subject
objects

zobserver and subject cooperate to maintain a constraint
zeasier to make reusable observers and subjects

zdifficult to understand the flow of communication

Discussion of Behavior Patterns

z

Decoupling Senders and Receivers (1)

–

Related patterns

zCommand
zObserver

zMediator

zChain of Responsibility

–

Command

zdecouples invokers and receiversby command objects
zallow senders to work with different receivers

za subclass for a sender-receiver connection
anInvoker

(sender) aCommand aReceiver(receiver)
Execute()

</div>
(4)<div class='page_container' data-page=4>

Discussion of Behavior Patterns

z

Decoupling Senders and Receivers (2)

–

Observer

zdecouples subjects and observersby an interface for
signaling changes

za subject may have multiple observers
zthe number of observers can vary at run-time
zbest for decoupling objects with data dependencies

aSubject

(sender) anObserver(receiver) anObserver(receiver)
Update()

anObserver
(receiver)

Update()
Update()

Discussion of Behavior Patterns

z

Decoupling Senders and Receivers (3)

–

Mediator

zdecouple objects (Colleagues)through a Mediator object
zroutes requests between Colleague objects

zcentralizes communication between Colleague objects
aColleague

(sender/receiver) aMediator (sender/receiver)aColleague

</div>
(5)<div class='page_container' data-page=5>

Discussion of Behavior Patterns

z

Decoupling Senders and Receivers (4)

–

Chain of Responsibility

zdecouple client and handlerby passing the request along a chain
zwhen the chain is part of the system’s structure

zwhen one of several objects may be in a position to handle the
request

aClient

(sender) (receiver)aHandler aHandler(receiver)
HandleHelp()

aHandler
(receiver)

HandleHelp()

Principle of OO Design

z

Principle of OO Design (p17-20)

–

Program to an interface, not an implementation

zcommit only to an abstract class interface

zhow to instantiate concrete classes?

–Abstract Factory, Builder, Factory Method, Prototype, and
Singleton.

–

Favor object composition over class inheritance

zsubclassing: white-box reuse

–inheritance breaks encapsulation

–change parent classes Ỉchange subclasses

–unmanageable monster classes and class hierarchies

zobject composition: black-box reuse

–requires carefully designed interface
–keep each class encapsulated

</div>
(6)<div class='page_container' data-page=6>

Pattern Structures

Design Patterns

z

Creational patterns

–

Abstract Factory

,

Builder

,

Factory Method

,

Prototype

,

Singleton

z

Structural patterns (composition)

–

Adaptor

,

Bridge

,

Composite

,

Decorator

,

Facade

,

Flyweight

,

Proxy

z

Behavioral patterns (interaction)

</div>
(7)<div class='page_container' data-page=7>

Creational patterns

Abstract Factory: Structure

AbstractProductA

ProductA2 ProductA1
AbstractProductB

ProductB2 ProductB1

CreateProductA()

CreateProductB()

AbstractFactory

CreateProductA()
CreateProductB()

ConcreteFactory1

CreateProductA()
CreateProductB()

ConcreteFactory2

</div>
(8)<div class='page_container' data-page=8>

Builder pattern: Structure

+Construct()
Director

for all objects in structure {
builder->BuildPart()
}

+BuildPart()
Builder
builder

+BuildPart()
+GetResult()

ConcreteBuilder

Product

Client

Product

ConcreteProduct

FactoryMethod()
AnOperation()

Creator

FactoryMethod()
ConcreteCreator

...

product = FactoryMethod();
...

return new ConcreteProduct;

Factory Method: Structure

</div>
(9)<div class='page_container' data-page=9>

Prototype: Structure

ConcretePrototype2
Client

Operation()

Prototype

Clone()

ConcretePrototype1

Clone() Clone()

prototype

p=prototype->Clone()

return copy of self return copy of self

Singleton

static Instance()

SingletonOperation()

GetSingletonData()

static uniqueInstance

singletonData

Singleton pattern: Structure

</div>
(10)<div class='page_container' data-page=10>

Structural patterns

Adapter: Structure (1)

Class adapter: use multiple inheritance

Target
Request()

Adapter
Request()

Adaptee

SpecificRequest()

</div>
(11)<div class='page_container' data-page=11>

Bridge pattern: Structure

+Operation()
Abstraction

RefinedAbstraction

imp->OperationImp()

+OperationImp()
Implementor

+OperationImp()
ConcreteImplementorA
imp

+OperationImp()
ConcreteImplementorB
Client

Adapter: Structure (2)

Object adapter: use object composition

Target
Request()

Adapter

Request()

Adaptee

SpecificRequest()
Client

adaptee->SpecificRequest()

</div>
(12)<div class='page_container' data-page=12>

Composite: Structure

Composite
Operation()
Add(Component)
Remove(Component)
GetChild(int)

Client

for all g in children
g.Operation() ;
Leaf

Operation()

Component
Operation()

Add(Component)
Remove(Component)
GetChild(int)

Decorator: Structure

Operation()

Decorator

Operation()
AddedBehavior()

ConcreteDecoratorB

component->Operation();

Decorator::Operation();
AddedBehavior();
Operation()

ConcreteComponent

Operation()
addedState

ConcreteDecoratorA
Operation()

Component

</div>
(13)<div class='page_container' data-page=13>

Facade: Structure

Facade

subsystem classes

Client

Flyweight: Structure

</div>
(14)<div class='page_container' data-page=14>

Proxy: Structure

Request()
...()

Subject

Request()
...()

Proxy ...

realSubject->Request();
...

Client

realSubject
Request()

...()

RealSubject

</div>
(15)<div class='page_container' data-page=15>

Command: Structure

Command
Execute()

receiver->Action()
receiver

ConcreteCommand
Execute()

state

Invoker

Client

Receiver
Action()

Mediator: Structure

mediator

Mediator

ConcreteMediator

Colleague

</div>
(16)<div class='page_container' data-page=16>

Observer: Structure

Subject

Attach(Observer)
Detach(Observer)
Notify()

ConcreteSubject
GetState()
SetState()
subjectState

Observer
Update()

ConcreteObserver
Update()

observerState

observerState = 
subject->GetState()
return subjectState

observers

subject

for all o in observers
o->Update();

State: Structure

State
Handle()

ConcreteStateA
Handle()

ConcreteStateB
Handle()
state->Handle()

Context
Request()

</div>
(17)<div class='page_container' data-page=17>

Strategy: Structure

Context

+ContextInterface()

Strategy

+Algorithminterface()

ConcreteStrategyA

+Algorithminterface()

ConcreteStrategyB

+Algorithminterface()

ConcreteStrategyC

+Algorithminterface()

Template Method: Structure

Abstract Class

TemplateMethod()

PrimitiveOperation1()
PrimitiveOperation2()

…

PrimitiveOperation1()
…

PrimitiveOperation2()
…

</div>
(18)<div class='page_container' data-page=18>

Visitor: Structure

ObjectStructure

Client

v->VisitConcreteElementA(this)

Visitor

VisitConcreteElementA(ConcreteElementA)
VisitConcreteElementB(ConcreteElementB)

ConcreteVisitor2

VisitConcreteElementA(ConcreteElementA)
VisitConcreteElementB(ConcreteElementB)
ConcreteVisitor1

VisitConcreteElementA(ConcreteElementA)
VisitConcreteElementB(ConcreteElementB)

Element
Accept(Visitor)

ConcreteElementA
Accept(Visitor v)
OperationA()

ConcreteElementB
Accept(Visitor v)
OperationB()

v->VisitConcreteElementB(this)

Design patterns: Conclusion

z

Documents existing designs

–

used by expert object-oriented designers

z

What to expect from design patterns (p351)

–

A Common Design Vocabulary

zto communicate, document, and explore design alternatives
zmake a system seem less complex Åtalking about it in a

higher level

–

A Documentation and Learning Aid

zmost large OO system use these design patterns

</div>
(19)<div class='page_container' data-page=19>

Design patterns: Conclusion

–

An Adjunct to Existing Methods

zis an important missing piece from OO design methods
zshow how to use primitive techniques (e.g., objects,

inheritance, and polymorphism)

zprovide a way to describe more of the “why” Ỉnot just
record the results of decisions.

zuseful in turning an analysis model into an implementation
model

–

A Target for Refactoring

zOO software lifecycle
–prototyping phase
–expansionary phase
–consolidating phase

expansion

prototyping consolidation
more requirements more reuse

Design patterns: Conclusion

z

Expansionary phase

– add new classes and operations
– new requirements are satisfied, but ...

zbecomes too inflexible for further change

zclasses define many unrelated operations and instance variables

z

Consolidating phase

– moving operations up or down the class hierarchy
– rationalizing the interface of classes

– tearing apart classes into special- and general-purpose components
zproduce many new kinds of objects

zdecomposing existing objects using object composition instead of
inheritance

zblack box reuse replace white box reuse.

– software becomes more general

z

Design patterns

– capture many structures results from refactoring
– provide targets for refactorings.

expansion

</div>

LectureConclusionpdf

Conclusions

Conclusions

<b>CSIE Department, NTUT</b>

<b>Woei-Kae Chen</b>

Discussion of Behavior Patterns

Discussion of Behavior Patterns

z

Encapsulating Variation (with inheritance; p345)

–

encapsulate an aspect that

changes frequently

–

Example

–

Advantage

–

Disadvantage

Discussion of Behavior Patterns

Discussion of Behavior Patterns

z

Encapsulating Variation (without inheritance)

–

define an

object

to encapsulate an aspect that

changes

frequently

–

Example

Discussion of Behavior Patterns

Discussion of Behavior Patterns

z

Object as arguments

–

Visitor

zis the argument to the

<b>accept</b>

operation

–

Command

zact as tokens to be passed around and invoked later

zthe token represents a request

–

Memento

Discussion of Behavior Patterns

Discussion of Behavior Patterns

z

Should communication be encapsulated or distributed?

–

Mediator Ù

Observer

–

Mediator

–

Observer

Discussion of Behavior Patterns

Discussion of Behavior Patterns

z

Decoupling Senders and Receivers (1)

–

Related patterns

–

Command

Discussion of Behavior Patterns

Discussion of Behavior Patterns

z

Decoupling Senders and Receivers (2)

–

Observer

Discussion of Behavior Patterns

Discussion of Behavior Patterns

z

Decoupling Senders and Receivers (3)

–

Mediator

Discussion of Behavior Patterns

Discussion of Behavior Patterns

z

Decoupling Senders and Receivers (4)