chapter 8 structural design patterns. process phases discussed in this chapter requirements analysis...

Chapter 8Structural Design Patterns

Process Phases Discussed in This ChapterRequirementsAnalysis

Design

Implementation

ArchitectureFramework Detailed Design

xKey: = secondary emphasisx = main emphasis

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Design Purpose

Provide an interface to a package of classes

Design Pattern Summary

Define a singleton which is the sole means

for obtaining functionality from the package.

Facade

Notes: the classes need not be organized as a package; more than one class may be used for the façade.


Facade Design Pattern Structure

C«not exposed»

myCMethod()

Façade«exposed»

cMethodOfFacade()Client1

2


Sequence Diagram for Façade

:Client

cMethodOfFacade()

singleton:Facade

:C

myCMethod()

(return if any)

(return if any)


Using Façade for Architecture of a Video Game

MyGameCharacters

MyGameEngine

MyGameCast«facade»

MyGame«facade»

MyGameEnvironment

MyGameEnvironment«facade»


Design Goals At Work: Correctness and

Reusability

Collecting customer-related classes in a package with a clear interface clarifies the design, allows independent verification, and makes this part reusable.


Using Façade to Access Bank Customers

bankCustomers

Clientmain()

«facade»BankCustomers

doDeposit( int amt, Customer cust, Account acc )getBankAccount( Customer cust, int accNum )

getBankCustomer( String custName )introduceApplication()

BankCustomer BankAccount

CustomergetCustomerName()getNumAccounts()getPersonalNote()getAccount( int )

AccountgetAccountNum()

deposit( int )getBalance()

1..n

IntroMessage

framework

AccountException

CustomerException


Output of Façade Banking Example


Key Concept: Facade Design Pattern

-- modularizes designs by hiding complexity


Design Purpose

Add responsibilities to an object at runtime.


Provide for a linked list of objects,

each encapsulating responsibility.

Decorator


Decorator Class Model

Client

objDecoratedDecoration

doAction()

1

SubstancedoAction()

Componentadd( Component )

doAction()

void doAction(){ ….. // do actions special to this decoration objDecorated.doAction(); // pass along}


Linked Objects in Decoratordecoration1:Decoration

decoration1.objectDecorated:Decoration

… :Decoration

….:Substance

client:Client


Sequence Diagram for Decorator

:Client

doAction()

decoration1:Decoration

doAction()

Decoration1.objDecorated:Decoration

:Substance

doAction()


Output of Customer/Account

Example


Decorator Applied to Customer / Accounts Example

Client

nextComponentAccountdescribe()

1

Customerdescribe()

BankingComponentadd( Component )

describe()

CheckAccountdescribe()

getLastCheckNum(): int

SavingsAccountdescribe()

getInterestRate(): int

CDAccountdescribe()

getDuration(): int

Setup

AttemptToAddBadBankingComponentException


Use of Decorator in java.io

InputStreamReaderInputStream BufferedReader

Reader1


java.io Decorator example

:InputStreamReader

System.in:InputStream

: BufferedStreamReader


Key Concept: Decorator Design Pattern

-- allows addition to and removal from objects at runtime


Design Purpose

Represent a Tree of Objects


Use a Recursive Form in which the

tree class aggregates and inherits

from the base class for the objects.

Composite


NonLeafNode

Basis for Composite Class Model

Component

“every object involvedis a Component object”

“non-leaf nodes have one or more

components”

leaf nodenon-leaf node

Objects

Classes 1..n


NonLeafNodedoIt()

Composite Class Model

etc.

component

Componentadd( Component )

doIt()

LeafNodedoIt()

TypeANonLeafNodedoIt()

TypeBNonLeafNodedoIt()

1..nClient

FOR ALL elements e in component e.doIt()


:LeafNodenonLeaf1ChildX:NonLeafNode

nonLeaf1ChildX:NonLeafNode

Sequence Diagram for Composite

:Client

doIt()

nonLeaf1:NonLeafNode

doIt()

doIt()

nonLeaf1ChildX:NonLeafNode

:LeafNode:LeafNode


Employee Hierarchy

Pete:President

Able:Manager

Becky:Manager

Lonny:Teller

Cal:Clerk

Tina:Teller

Thelma:Teller


Design Goal At Work: Flexibility, Correctness

We need to add and remove employees at runtime and execute operations on all of them.


Bank/Teller Example

Client

reports

Supervisoradd(Employee)

EmployeestateName()

1..n

Setup

ClerkstateName()

PresidentstateName()

TellerstateName()

ManagerstateName()


Sequence Diagram for Bank/Teller Example

:Client

stateName()

pete:President

xxxx:Employee

:Setp

doClientTasks()

stateName()

xxxx:Employee

xxxx:Employee

xxxx:Employee

*

• Creates the tree of Employee objectswith Pete as President


Output of Bank/Teller Example


ComponentComposite in java.awt

Container

Window … . .

component

1..n

Canvas


Attempt to Simplify Composite

Component0…n

children


Key Concept: Composite Design Pattern

-- used to represent trees of objects.


Design Purpose

Allow an application to use external functionality in a retargetable manner.


Write the application against an abstract version of the external class; introduce a subclass that aggregates the external class.

Adapter


Adapter Example

Client

AbstractClassclientNameForRequiredMethod()

AdapterclientNameForRequiredMethod()

{ adaptee. requiredMethod();}

adaptee

RequiredClassrequiredMethod()


Sequence Diagram for Adapter

:Client

clientNameForRequiredMethod()

:AbstractClass :Adapter

RequiredMethod()

adaptee:RequiredClass


Design Goal At Work: Flexibility and

Robustness

We want to separate the application as a whole from financial calculations which will be performed externally.


Adapter Design Pattern

Financialamount() Principle

computeValue()

Client

Legacy systemAdaptationApplication


Adaptation

MyListeneractionPerformed()

Java Listeners as Adapters

Result of button press

MyButtonaddActionListener()

ActionListener

MyClassmyMethod()

actionListener


Adapter Example: Inheritance Version

Client

AbstractClassstandinForRequiredMethod()

AdapterstandinForRequiredMethod()

{ requiredMethod();}

RequiredClassrequiredMethod()


Key Concept: Adapter Design Pattern

-- to interface flexibly with external functionality.


Design Purpose

Manage a large number of objects

without constructing them all.


Share representatives for the objects; use

context to obtain the effect of multiple instances.

Flyweight


Flyweight

Flyweight Class Model

FlyweightdoAction(Context)

ConcreteFlyweightdoAction(Context)

FlyweightFactorygetFlyweight(Characteristic)

Client

1..n


Sequence Diagram for Flyweight

:Client

getFlyweight()

:FlyweightFactory flyweight:Flyweight

doAction( context )

Get context

flyweight

. . . .


Flyweight Example: Text

Magnifier

Input

ABBRA CADABBRAA ARE THE FIRST TWO OF MANY WORDS IN

THIS FILE …

Output

o

o o

o o

o o

o o o o o

o o

o o

v v v

v v

v v

- R E D -

v v

v v

v v v

. . . . . .

1

2 Input color: RED ….. Starting character: 2 … Ending character: 3

v v v

v v

v v

- R E D -

v v

v v

v v vAdapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

When Space is No Limitation:Linked BigCharacter Objects

A1:BigACharactercolor == “black”

…

A1:BigACharactercolor “red”letter “o”…

B1:BigBCharactercolor == “red”

…

A2:BigACharactercolor “black”letter “o”…

B1:BigBCharactercolor “red”letter “v”…

B2:BigBCharactercolor “black”letter “v”…

R1:BigRCharactercolor “black”letter “x”…


Design Goal At Work: Space Efficiency

We want to avoid proliferating an object for every big character to be displayed.


Flyweights (1 each)

Line for output

Use string to determine which flyweight . Use color information to form the context (parameter value).

Make (shared) BigA, BigB, …

flyweight object available to clients

Mapping “A”, “B” etc. to a BigA BigB etc. object

Client Responsibilities DP Responsibilities

v v v

v v

v v

- r e d -

v v

v v

v v v

. . . . . .

bigA:BigA

bigB:BigB

v v v

v v

v v

b l a c k

v v

v v

v v v

getMatrix( ”red” )

getMatrix( “black” )

color “RED” begins 0 …

ABBRA CADABBRA …


Typical Output For Large Type

ExampleAdapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Application of Flyweight

BigCharacter Flyweight Application: Class Model

BigCharconstructionChar

getMatrix( String color )

BigCharFactorygetFlyweight( char )

PagePrinter

26

«singleton»BigB

«singleton»BigA


Key Concept: Flyweight Design Pattern

-- to obtain the benefits of a large set of individual objects without efficiency penalties.


Design Purpose

Avoid the unnecessary execution of expensive

functionality in a manner transparent to clients.


Interpose a substitute class which accesses the

expensive functionality only when required.

Proxy


AdaptationProxy Design

Pattern BaseActiveClassexpensiveMethod()anotherMethod()

RealActiveClassexpensiveMethod()anotherMethod()

ProxyexpensiveMethod()anotherMethod()

Client

realActiveObject

. . . // One way to check if really needed:if ( realActiveObject == null ) // never referenced{ realActiveObject = getRealActiveObject(); realActiveObject.expensiveMethod(); }else // try to avoid calling the real expensiveMethod()

Instantiate withProxy object


realExpensiveMethod()

Sequence Diagram for Proxy

:Client

expensiveMethod()

:Proxy :RealActiveClass

( if needed: )


I/O of Telephone Record Proxy

Example


Design Goal At Work: Efficiency and

Reuse

Avoid unnecessary data downloads.


TelNumsvalue: Vector

getTelNums(): VectorshowMiddleRecord()

RemoteTelNumsgetTelNums()

TelNumsProxygetTelNums()

TelephoneAppdisplay( TelNums )

display MiddleRecord()

remoteTelNums

. . . // One way to check if really needed:if ( value == null ) // never referenced

remoteTelNums.getTelNums(); else // no need to call ‘getTelNums()’

static

1

Proxy Example

Setup

Ensures that TelephoneApp makes calls with TelNumsProxyinstance


Key Concept: Proxy Design Pattern

-- to call expensive or remote methods.


Structural Design Patterns relate objects (as trees, lists etc.)

Facade provides an interface to collections of objects

Decorator adds to objects at runtime

Composite represents trees of objects

Adapter simplifies the use of external functionality

Flyweight gains the advantages of using multiple

instances while minimizing space penalties

Proxy avoids calling expensive operations unnecessarily

Summary of Structural Patterns


“Queuing Configuration” Exercise

Lonny

Juanita

Tina

Thelma

c

c

cc

c c c

c c c c c

Key: “c”

== a customer

Tellers

Customer being

servedQueues


Solution to Exercise 8.1 “Queueing Configurations”

Clientqueues

QueueForTellersadd( Queue

Queue….()

1..n

Setup

QueueForOneTeller….() Teller


Using Façade

xInventory

Clientmain()

«facade»XInventoryFacade

…( … )

Xinventory…( … )

Toaster

Inventory…( … )

InventoryItem…( … )

1..n

XIntroMessage

inventoryFramework

InventoryItemException

ToasterToaster1


Decorator Applied to Construction Example

Client

nextComponentConstrMaterial

showPrice()

1

ConstrJobadd()

showPrice()

ConstructionComponentadd( Component )

showPrice()

WindowshowPrice()

…

DoorshowPrice()

…

BeamshowPrice()

…

Setup

construction


Typical Stencil Placement on a Wall


Typical Wall Perspective

etc.


chapter 8 structural design patterns. process phases discussed in this chapter requirements analysis...

Documents

software design

braude wiley

design goals

design purposeprovide

design pattern summaryprovide

customerrelated classes

linked objects

linked list of objects