Chapter 8 Structural Design Patterns

1
Chapter 8Structural Design Patterns

• Facade
• Decorator
• Composite
• Adapter
• Flyweight
• Proxy

2
Façade Design Pattern
3
Design Purpose
Facade
Provide an interface to a package of classes
Design Pattern Summary
Define a class (typically a singleton) that is
the sole means for obtaining functionality from
the package.
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.
4
Facade Design Pattern Structure
1
Façade exposed cMethodOfFacade()
Client
2
C not exposed myCMethod()
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
5
Sequence Diagram for Façade
Client
singleton Facade
C
cMethodOfFacade()
myCMethod()
(return if any)
(return if any)
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
6
Using Façade for Architecture of a Video Game
MyGameEngine
MyGame facade
MyGameCharacters
packages
MyGameCast facade
MyGameEnvironment
MyGameEnvironment facade
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
7
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.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
8
Using Façade to Access Bank Customers
ltltinterfacegtgt
ltltinterfacegtgt
Customer getCustomerName() getNumAccounts() getPer
sonalNote() getAccount( int )
Account getAccountNum() deposit( int
) getBalance()
AccountException
CustomerException
framework
1..n
BankCustomer
BankAccount
IntroMessage
package
facade BankCustomers doD
eposit( int amt, Customer cust, Account acc
) getBankAccount( Customer cust, int accNum
) getBankCustomer( String custName
) introduceApplication()
Client main()
bankCustomers
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
9
Key Concept ? Facade Design Pattern ?
-- modularizes designs by hiding complexity
(similar to the web services provided by a web
site)
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
10
Decorator Design Pattern
11
Design Purpose
Decorator
Add responsibilities to an object at runtime.
Design Pattern Summary
Provide for a linked list of objects, each
encapsulating responsibility.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
12
Decorator Class Model
Component add( Component ) doAction()
1
Client
Decoration doAction()
Substance doAction()
objDecorated
void doAction() .. // do actions special to
this decoration objDecorated.doAction() //
pass along
Undecorated class
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
13
Linked Objects in Decorator
clientClient
decoration1Decoration
decoration1.objectDecoratedDecoration
Decoration
.Substance
This list is created backwards so that the last
decoration added is the first one to be executed
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
14
Sequence Diagram for Decorator
Client
decoration1 Decoration
Decoration1.objDecorated Decoration
Substance
doAction()
doAction()
doAction()
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
15
Decorator Applied to Customer / Accounts Example
AttemptToAddBadBankingComponentException
ltltinterfacegtgt
Means exactly one aggregate per account
BankingComponent add( Component ) describe()
1
Client
nextComponent
Setup
Account describe()
Customer describe()
main()
CheckAccount describe() getLastCheckNum() int
SavingsAccount describe() getInterestRate() int
CDAccount describe() getDuration() int
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
16
Decorator Applied to Construction Example
construction
ConstructionComponent add( Component ) showPrice()
1
Client
nextComponent
Setup
ConstrJob add() showPrice()
ConstrMaterial showPrice()
Window showPrice()
Door showPrice()
Beam showPrice()
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
17
Use of Decorator in java.io
Reader
1
InputStreamReader
BufferedReader
InputStream
BufferedReader bufReader new BufferedReader
(new InputStreamReader(System.in) )
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
18
Key Concept ? Decorator Design Pattern ?
-- allows addition to and removal from objects at
runtime -- represents an object version of a
linked list where a client does not need to know
about the subclasses in the list -- emphasizes
the structural properties of the substance in the
list
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
19
Composite Design Pattern
20
Composite
Design Purpose
Represent a Tree of Objects
Design Pattern Summary
Use a recursive form in which the tree class
aggregates and inherits from the base class for
the objects.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
21
Basis for Composite Class Model
Objects
leaf node
non-leaf node
1..n
Classes
Component
non-leaf nodes have one or more components
every object involved is a Component object
NonLeafNode
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
22
Composite Class Model
Component add( Component ) doIt()
1..n
Client
FOR ALL elements e in component e.doIt()
NonLeafNode doIt()
LeafNode doIt()
component
etc.
TypeANonLeafNode doIt()
TypeBNonLeafNode doIt()
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
23
Sequence Diagram for Composite
Client
nonLeaf1 NonLeafNode
nonLeaf1ChildX NonLeafNode
LeafNode
nonLeaf1ChildX NonLeafNode
LeafNode
LeafNode
nonLeaf1ChildX NonLeafNode
doIt()
doIt()
doIt()
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
24
Employee Hierarchy
Pete President
Able Manager
Becky Manager
Tina Teller
Lonny Teller
Cal Clerk
Thelma Teller
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
25
Design Goal At Work ? Flexibility, Correctness
?
We need to add and remove employees at runtime
and execute operations on all of them.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
26
Bank/Teller Example
Composite Design Pattern
1..n
Employee stateName()
Client
reports
Clerk stateName()
Supervisor add(Employee)
Teller stateName()
Setup
President stateName()
Manager stateName()
main()
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
27
Sequence Diagram for Bank/Teller Example
Setp
Client
pete President
xxxx Employee
xxxx Employee
xxxx Employee
xxxx Employee

doClientTasks()
stateName()
stateName()

• Creates the tree of Employee objects
• with Pete as President

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
28
Composite in java.awt
Component
1..n
Container
component
. .
Window
Canvas
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
29
Key Concept ? Composite Design Pattern ?
-- used to represent trees of objects.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
30
Adapter Design Pattern
31
Adapter
Design Purpose
Allow an application to use external
functionality in a retargetable manner.
Design Pattern Summary
Write the application against an abstract version
of the external class introduce a subclass that
aggregates the external class.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
32
Adapter Example
AbstractClass clientNameForRequiredMethod()
RequiredClass requiredMethod()
Client
adaptee
Adapter clientNameForRequiredMethod()
adaptee. requiredMethod()
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
33
Sequence Diagram for Adapter
Client
AbstractClass
Adapter
adaptee RequiredClass
clientNameForRequiredMethod()
RequiredMethod()
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
34
Design Goal At Work ? Flexibility and
Robustness ?
We want to separate the application as a whole
from financial calculations which will be
performed externally.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
35
Adapter Design Pattern
Legacy system
Adaptation
Application
Financial amount()
Principle computeValue()
FinancialAdapter amount()
Client
Setup code in the client instantiates the
Financial object as a FinancialAdapter instance
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
36
Code Example
class FinancialAdapter extends Financial
Principal legacyAdaptee null //
Constructor goes here . . . // This method
uses the legacy computeValue() method float
amount(float originalAmount, float numYears,
float intRate) return legacyAdaptee.comput
eValue(orginalAmount, numYears, intRate)
executeFinanceApplication(new FinancialAdapter()
)
37
Key Concept ? Adapter Design Pattern ?
-- to interface flexibly with external
functionality.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
38
Flyweight Design Pattern
39
Flyweight
Design Purpose
Manage a large number of almost indistinguishable
objects without constructing them all at once.
Design Pattern Summary
Share representatives for the objects use
context to obtain the effect of multiple
instances.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
40
Flyweight Class Model
Client
Flyweight
1..n
Flyweight doAction(Context)
FlyweightFactory getFlyweight(Characteristic)
static method
ConcreteFlyweight doAction(Context)
singleton
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
41
Sequence Diagram for Flyweight
Client
FlyweightFactory
flyweight Flyweight
getFlyweight()
flyweight
Get context
. . . .
doAction( context )
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
42
Example A Window size of 15 folder contains 20
items
43
Example B Window size of 15 folder contains
over 500 items
Each line item had a drawing window associated
with it
44
Design Goal At Work ? Space Efficiency ?
We want to avoid proliferating an object for
every item to be displayed.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
45
Key Concept ? Flyweight Design Pattern ?
-- to obtain the benefits of a large set of
individual objects without efficiency penalties.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
46
Proxy Design Pattern
47
Proxy
Design Purpose
Avoid the unnecessary execution of expensive
functionality in a manner transparent to clients.
Design Pattern Summary
Interpose a substitute class which accesses the
expensive functionality only when required.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
48
Proxy Design Pattern
Client
ltltabstractgtgt
Adaptation
BaseActiveClass expensiveMethod() anotherMethod()
Instantiate with Proxy object
RealActiveClass expensiveMethod() anotherMethod()
Proxy expensiveMethod() anotherMethod()
realActiveObject
. . . // One way to check if it is really
needed if ( realActiveObject null )
// never referenced realActiveObject
getRealActiveObject() realActiveObject.exp
ensiveMethod() else // try to avoid calling
the real expensiveMethod()
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
49
Sequence Diagram for Proxy
Client
Proxy
RealActiveClass
expensiveMethod()
( if needed )
realExpensiveMethod()
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
50
I/O of Telephone Record Proxy Example
gt all
gt middle
gt all
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
51
Design Goal At Work ? Efficiency and Reuse ?
Avoid unnecessary data downloads.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
52
Proxy Example
TelNums value Vector getTelNums()
Vector showMiddleRecord()
TelephoneApp display( TelNums ) display
MiddleRecord()
static
RemoteTelNums getTelNums()
TelNumsProxy getTelNums()
remoteTelNums
1
Setup
. . . // One way to check if really needed if (
value null ) // never referenced remoteTelNu
ms.getTelNums() else // no need to call
getTelNums()
Ensures that TelephoneApp makes calls with
TelNumsProxy instance
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
53
Key Concept ? Proxy Design Pattern ?
-- to call expensive or remote methods.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
54
Summary of Structural Design Patterns

• Structural Design Patterns relate objects (as
  trees, lists etc.)
• Facade provides an interface to collections of
  objects
• Decorator adds to objects at runtime (in a list
  structure)
• 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

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