Upload
avak
View
41
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Chapter 8 Structural Design Patterns. Process Phases Discussed in This Chapter. Requirements Analysis. Design. Framework. Architecture. Detailed Design. Implementation. Key:. = main emphasis. = secondary emphasis. x. x. - PowerPoint PPT Presentation
Citation preview
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.
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Facade Design Pattern Structure
C«not exposed»
myCMethod()
Façade«exposed»
cMethodOfFacade()Client1
2
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Sequence Diagram for Façade
:Client
cMethodOfFacade()
singleton:Facade
:C
myCMethod()
(return if any)
(return if any)
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Using Façade for Architecture of a Video Game
MyGameCharacters
MyGameEngine
MyGameCast«facade»
MyGame«facade»
MyGameEnvironment
MyGameEnvironment«facade»
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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.
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
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Output of Façade Banking Example
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Key Concept: Facade Design Pattern
-- modularizes designs by hiding complexity
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Design Purpose
Add responsibilities to an object at runtime.
Design Pattern Summary
Provide for a linked list of objects,
each encapsulating responsibility.
Decorator
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Decorator Class Model
Client
objDecoratedDecoration
doAction()
1
SubstancedoAction()
Componentadd( Component )
doAction()
void doAction(){ ….. // do actions special to this decoration objDecorated.doAction(); // pass along}
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Linked Objects in Decoratordecoration1:Decoration
decoration1.objectDecorated:Decoration
… :Decoration
….:Substance
client:Client
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Sequence Diagram for Decorator
:Client
doAction()
decoration1:Decoration
doAction()
Decoration1.objDecorated:Decoration
:Substance
doAction()
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Output of Customer/Account
Example
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Decorator Applied to Customer / Accounts Example
Client
nextComponentAccountdescribe()
1
Customerdescribe()
BankingComponentadd( Component )
describe()
CheckAccountdescribe()
getLastCheckNum(): int
SavingsAccountdescribe()
getInterestRate(): int
CDAccountdescribe()
getDuration(): int
Setup
AttemptToAddBadBankingComponentException
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Use of Decorator in java.io
InputStreamReaderInputStream BufferedReader
Reader1
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
java.io Decorator example
:InputStreamReader
System.in:InputStream
: BufferedStreamReader
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Key Concept: Decorator Design Pattern
-- allows addition to and removal from objects at runtime
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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.
Composite
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
NonLeafNodedoIt()
Composite Class Model
etc.
component
Componentadd( Component )
doIt()
LeafNodedoIt()
TypeANonLeafNodedoIt()
TypeBNonLeafNodedoIt()
1..nClient
FOR ALL elements e in component e.doIt()
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
:LeafNodenonLeaf1ChildX:NonLeafNode
nonLeaf1ChildX:NonLeafNode
Sequence Diagram for Composite
:Client
doIt()
nonLeaf1:NonLeafNode
doIt()
doIt()
nonLeaf1ChildX:NonLeafNode
:LeafNode:LeafNode
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Employee Hierarchy
Pete:President
Able:Manager
Becky:Manager
Lonny:Teller
Cal:Clerk
Tina:Teller
Thelma:Teller
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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.
Bank/Teller Example
Client
reports
Supervisoradd(Employee)
EmployeestateName()
1..n
Setup
ClerkstateName()
PresidentstateName()
TellerstateName()
ManagerstateName()
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Output of Bank/Teller Example
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
ComponentComposite in java.awt
Container
Window … . .
component
1..n
Canvas
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Attempt to Simplify Composite
Component0…n
children
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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.
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.
Adapter
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Adapter Example
Client
AbstractClassclientNameForRequiredMethod()
AdapterclientNameForRequiredMethod()
{ adaptee. requiredMethod();}
adaptee
RequiredClassrequiredMethod()
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Sequence Diagram for Adapter
:Client
clientNameForRequiredMethod()
:AbstractClass :Adapter
RequiredMethod()
adaptee:RequiredClass
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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.
Adapter Design Pattern
Financialamount() Principle
computeValue()
Client
Legacy systemAdaptationApplication
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Adaptation
MyListeneractionPerformed()
Java Listeners as Adapters
Result of button press
MyButtonaddActionListener()
ActionListener
MyClassmyMethod()
actionListener
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Adapter Example: Inheritance Version
Client
AbstractClassstandinForRequiredMethod()
AdapterstandinForRequiredMethod()
{ requiredMethod();}
RequiredClassrequiredMethod()
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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.
Design Purpose
Manage a large number of objects
without constructing them all.
Design Pattern Summary
Share representatives for the objects; use
context to obtain the effect of multiple instances.
Flyweight
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Flyweight
Flyweight Class Model
FlyweightdoAction(Context)
ConcreteFlyweightdoAction(Context)
FlyweightFactorygetFlyweight(Characteristic)
Client
1..n
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Sequence Diagram for Flyweight
:Client
getFlyweight()
:FlyweightFactory flyweight:Flyweight
doAction( context )
Get context
flyweight
. . . .
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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”…
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Design Goal At Work: Space Efficiency
We want to avoid proliferating an object for every big character to be displayed.
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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 …
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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.
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.
Proxy
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
realExpensiveMethod()
Sequence Diagram for Proxy
:Client
expensiveMethod()
:Proxy :RealActiveClass
( if needed: )
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
I/O of Telephone Record Proxy
Example
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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.
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
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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.
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
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
“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
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Solution to Exercise 8.1 “Queueing Configurations”
Clientqueues
QueueForTellersadd( Queue
Queue….()
1..n
Setup
QueueForOneTeller….() Teller
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Using Façade
xInventory
Clientmain()
«facade»XInventoryFacade
…( … )
Xinventory…( … )
Toaster
Inventory…( … )
InventoryItem…( … )
1..n
XIntroMessage
inventoryFramework
InventoryItemException
ToasterToaster1
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Decorator Applied to Construction Example
Client
nextComponentConstrMaterial
showPrice()
1
ConstrJobadd()
showPrice()
ConstructionComponentadd( Component )
showPrice()
WindowshowPrice()
…
DoorshowPrice()
…
BeamshowPrice()
…
Setup
construction
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Typical Stencil Placement on a Wall
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Typical Wall Perspective
etc.
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.