Chapter 8 Structural Design Patterns

Process Phases Discussed in This Chapter Requirements Analysis Design Implementation ArchitectureFramework Detailed Design x Key:= secondary emphasis x = 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() Client 1 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) 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 «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 Client main() «facade» BankCustomers doDeposit( int amt, Customer cust, Account acc ) getBankAccount( Customer cust, int accNum ) getBankCustomer( String custName ) introduceApplication() BankCustomerBankAccount Customer getCustomerName() getNumAccounts() getPersonalNote() getAccount( int ) Account getAccountNum() 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 objDecorated Decoration doAction() 1 Substance doAction() Component add( 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 Decorator decoration1: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 nextComponent Account describe() 1 Customer describe() BankingComponent add( Component ) describe() CheckAccount describe() getLastCheckNum(): int SavingsAccount describe() getInterestRate(): int CDAccount describe() 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 InputStreamReader InputStream BufferedReader Reader 1 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 involved is 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.

NonLeafNode do I t() Composite Class Model etc. component Component add( Component ) do I t() LeafNode do I t() TypeANonLeafNode do I t() TypeBNonLeafNode do I t() 1..n Client FOR ALL elements e in component e.do I t() 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() nonLeaf1ChildX :NonLeafNode :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 Supervisor add(Employee) Employee stateName() 1..n Setup Clerk stateName() President stateName() Teller stateName() Manager stateName() 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 objects with 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.

Component Composite 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 Component 0…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 AbstractClass clientNameForRequiredMethod() Adapter clientNameForRequiredMethod() { adaptee. requiredMethod();} adaptee RequiredClass requiredMethod() 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 Financial amount() Principle computeValue() Client Legacy systemAdaptationApplication Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Adaptation MyListener actionPerformed() Java Listeners as Adapters Result of button press MyButton addActionListener() ActionListener MyClass myMethod() actionListener Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Adapter Example: Inheritance Version Client AbstractClass standinForRequiredMethod() Adapter standinForRequiredMethod() { requiredMethod();} RequiredClass requiredMethod() 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 Flyweight doAction(Context) ConcreteFlyweight doAction( Context ) FlyweightFactory getFlyweight(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 oo oo oo ooooo oo oo vvv vv v v -RED- vv vv vvv Input color: RED ….. Starting character: 2 … Ending character: 3 vvv vv v v -RED- vv vv vvv Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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”… 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 ResponsibilitiesDP Responsibilities vvv vv v v -red- vv vv vvv... bigA:BigA bigB:BigB vvv vv v v black vv vv vvv 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 Example Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Application of Flyweight BigCharacter Flyweight Application: Class Model BigChar constructionChar getMatrix( String color ) BigCharFactory getFlyweight( 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.

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

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 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.) o Facade provides an interface to collections of objects o Decorator adds to objects at runtime o Composite represents trees of objects o Adapter simplifies the use of external functionality o Flyweight gains the advantages of using multiple instances while minimizing space penalties o 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 c c c c c c c c c c Key: “c” == a customer Tellers Customer being served Queues Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Solution to Exercise 8.1 “Queueing Configurations” Client queues QueueForTellers add( 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 Client main() «facade» XInventoryFacade …( … ) Xinventory …( … ) Toaster Inventory …( … ) InventoryItem …( … ) 1..n XIntroMessage inventoryFramework InventoryItemException Toaster 1 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Decorator Applied to Construction Example Client nextComponent ConstrMaterial showPrice() 1 ConstrJob add() showPrice() ConstructionComponent add( Component ) showPrice() Window showPrice() … Door showPrice() … Beam showPrice() … 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.