8 structural design patterns - mississippi state...

Software Architecture – Structural Design Patterns 1

Chapter 8 Structural Design Patterns


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.

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


C «not exposed» myCMethod()

Façade «exposed»

cMethodOfFacade() Client 1

2


Facade Design Pattern Structure


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

Client main()

«facade» BankCustomers

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

getBankCustomer( String custName ) introduceApplication()

BankCustomer BankAccount

Customer getCustomerName() getNumAccounts() getPersonalNote() getAccount( int )

Account getAccountNum()

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

objDecorated Decoration

doAction()

1

Substance doAction()

Component add( Component )

doAction()

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



Linked Objects in Decorator decoration1: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


Process Phases Discussed in This Chapter Requirements Analysis

Design

Implementation

Architecture Framework Detailed Design

x Key: = secondary emphasis x = main emphasis



Decorator Applied to Customer /

Accounts Example

Client

nextComponent Account describe()

1

Customer describe()

BankingComponent add( Component )

describe()

CheckAccount describe()

getLastCheckNum(): int

SavingsAccount describe()

getInterestRate(): int

CDAccount describe()

getDuration(): int

Setup

AttemptToAddBadBankingComponentException


Use of Decorator in java.io

InputStreamReader InputStream BufferedReader

Reader 1



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 involved is a Component object”

“non-leaf nodes have one or more

components”

leaf node non-leaf node

Objects

Classes 1..n



NonLeafNode doIt()

Composite Class Model

etc.

component

Component add( Component )

doIt()

LeafNode doIt()

TypeANonLeafNode doIt()

TypeBNonLeafNode doIt()

1..n Client

FOR ALL elements e in component e.doIt()


:LeafNode nonLeaf1ChildX :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

Supervisor add(Employee)

Employee stateName()

1..n

Setup

Clerk stateName()

President stateName()

Teller stateName()

Manager stateName()


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 objects with Pete as President



Output of Bank/Teller Example



Component

Composite in java.awt

Container

Window … . .

component

1..n

Canvas



Attempt to Simplify Composite

Component 0…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

AbstractClass clientNameForRequiredMethod()

Adapter clientNameForRequiredMethod()

{ adaptee. requiredMethod();}

adaptee

RequiredClass requiredMethod()



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

Financial amount() Principle

computeValue()

Client

Legacy system Adaptation Application

FinancialAdapter amount() legacyAdaptee

{ legacyAdaptee.computeValue(); }



Adaptation

MyListener actionPerformed()

Java Listeners as Adapters

Result of button press

MyButton addActionListener()

ActionListener

MyClass myMethod()

actionListener



Adapter Example: Inheritance Version

Client

AbstractClass standinForRequiredMethod()

Adapter standinForRequiredMethod()

{ requiredMethod();}

RequiredClass requiredMethod()



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

Flyweight doAction(Context)

ConcreteFlyweight doAction(Context)

FlyweightFactory getFlyweight(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 oo o

o oo o o o o

o oo o

v v vv vv v- R E D - v v

v vv v v

. . . . . .

1

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

v v vv vv v- R E D - v v

v vv v v



When Space is No Limitation: Linked BigCharacter Objects

A1:BigACharacter color == “black”

…

A1:BigACharacter color “red” letter “o”…

B1:BigBCharacter color == “red”

…

A2:BigACharacter color “black” letter “o”…

B1:BigBCharacter color “red” letter “v”…

B2:BigBCharacter color “black” letter “v”…

R1:BigRCharacter color “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 Example



Application of Flyweight

BigCharacter Flyweight Application: Class Model

BigChar constructionChar

getMatrix( String color )

BigCharFactory getFlyweight( 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



Adaptation

Proxy Design Pattern

BaseActiveClass expensiveMethod()

anotherMethod()

RealActiveClass expensiveMethod()

anotherMethod()

Proxy expensiveMethod()

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 with Proxy 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.



TelNums value: Vector

getTelNums(): Vector showMiddleRecord()

RemoteTelNums getTelNums()

TelNumsProxy getTelNums()

TelephoneApp display( 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 TelNumsProxy instance



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


8 structural design patterns - mississippi state...

Documents