LectureConclusionpdf

– Abstract Factory, Builder, Factory Method, Prototype, and Singleton. – Favor object composition over class inheritance[r]

1 Conclusions

Conclusions

CSIE Department, NTUT Woei-Kae Chen

2

Discussion of Behavior Patterns Discussion of Behavior Patterns

zEncapsulating 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

3

Discussion of Behavior Patterns Discussion of Behavior Patterns

zEncapsulating Variation (without inheritance)

– define an objectto 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 Discussion of Behavior Patterns

zObject as arguments

– Visitor

zis the argument to the acceptoperation

– Command

zact as tokens to be passed around and invoked later zthe token represents a request

– Memento

5

Discussion of Behavior Patterns Discussion of Behavior Patterns

zShould 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

6

Discussion of Behavior Patterns Discussion of Behavior Patterns

zDecoupling 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()

7

Discussion of Behavior Patterns Discussion of Behavior Patterns

zDecoupling 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 Discussion of Behavior Patterns

zDecoupling 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

9

Discussion of Behavior Patterns Discussion of Behavior Patterns

zDecoupling 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()

HandleHelp()

10

Principle of OO Design Principle of OO Design

zPrinciple 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

11

Pattern Structures Pattern Structures

Design Patterns Design Patterns

zCreational patterns

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

zStructural patterns (composition)

– Adaptor, Bridge, Composite, Decorator, Facade,

Flyweight, Proxy

zBehavioral patterns (interaction)

13

Creational patterns Creational patterns

14

Abstract Factory: Structure Abstract Factory: Structure

AbstractProductA

ProductA2 ProductA1 AbstractProductB

ProductB2 ProductB1

CreateProductA() CreateProductB()

AbstractFactory

CreateProductA() CreateProductB()

ConcreteFactory1

CreateProductA() CreateProductB()

ConcreteFactory2

15

Builder pattern: Structure 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 Factory Method: Structure

17

Prototype: Structure Prototype: Structure

ConcretePrototype2 Client

Operation()

Prototype

Clone()

ConcretePrototype1

Clone() Clone()

prototype

p=prototype->Clone()

return copy of self return copy of self

18

Singleton static Instance() SingletonOperation() GetSingletonData() static uniqueInstance singletonData

Singleton pattern: Structure Singleton pattern: Structure

19

Structural patterns Structural patterns

Adapter: Structure (1) Adapter: Structure (1) Class adapter: use multiple inheritance

Target Request()

Adapter Request()

Adaptee

SpecificRequest()

SpecificRequest()

21

Bridge pattern: Structure Bridge pattern: Structure

+Operation() Abstraction

RefinedAbstraction

imp->OperationImp()

+OperationImp() Implementor

+OperationImp() ConcreteImplementorA imp

+OperationImp() ConcreteImplementorB Client

22

Adapter: Structure (2) Adapter: Structure (2) Object adapter: use object composition

Target Request()

Adapter Request()

Adaptee

SpecificRequest() Client

adaptee->SpecificRequest()

23

Composite: Structure 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 Decorator: Structure

Operation()

Decorator

Operation() AddedBehavior()

ConcreteDecoratorB

component->Operation();

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

ConcreteComponent

Operation() addedState

ConcreteDecoratorA Operation()

Component

25

Facade: Structure Facade: Structure

Facade

subsystem classes

Client

26

Flyweight: Structure Flyweight: Structure

27

Proxy: Structure Proxy: Structure

Request() ()

Subject

Request() ()

Proxy

realSubject->Request();

Client

realSubject Request()

()

RealSubject

29

Command: Structure Command: Structure

Command Execute()

receiver->Action() receiver

ConcreteCommand Execute()

state Invoker

Client

Receiver Action()

30

Mediator: Structure Mediator: Structure

mediator

Mediator

ConcreteMediator

Colleague

31

Observer: Structure 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: Structure

State Handle()

ConcreteStateA Handle()

ConcreteStateB Handle() state->Handle()

Context Request()

33

Strategy: Structure Strategy: Structure

Context

+ContextInterface()

Strategy +Algorithminterface()

ConcreteStrategyA

+Algorithminterface()

ConcreteStrategyB

+Algorithminterface()

ConcreteStrategyC

+Algorithminterface()

34

Template Method: Structure Template Method: Structure

Abstract Class

TemplateMethod()

PrimitiveOperation1() PrimitiveOperation2()

…

PrimitiveOperation1() …

PrimitiveOperation2() …

35

Visitor: Structure 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 Design patterns: Conclusion

zDocuments existing designs

– used by expert object-oriented designers

zWhat 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

37

Design patterns: Conclusion 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

38

Design patterns: Conclusion 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