1. Chapter 8 Structural Design Patterns o Facade o Decorator o Composite o Adapter o Flyweight o Proxy

2. Façade Design Pattern

3. Design Purpose 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. 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.

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

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

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

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

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

12. 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. Undecorated class

13. 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. This list is created backwards so that the last decoration added is the first one to be executed

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

15. 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. >Means exactly one aggregate per account main()

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

17. 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. BufferedReader bufReader = new BufferedReader (new InputStreamReader(System.in) );

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

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

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

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

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

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 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. main() Composite Design Pattern

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

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

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

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

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

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 Financial amount() Principle computeValue() Client Legacy systemAdaptationApplication Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission. FinancialAdapter amount() Setup code in the client instantiates the Financial object as a FinancialAdapter instance

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.computeValue(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. 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. Flyweight Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

40. 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. static method singleton

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

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

48. Adaptation Proxy Design Pattern BaseActiveClass expensiveMethod() anotherMethod() RealActiveClass expensiveMethod() anotherMethod() Proxy expensiveMethod() anotherMethod() Client realActiveObject... // One way to check if it is 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. >

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

50. I/O of Telephone Record Proxy Example Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission. > all > middle > all

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

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. 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 (in a list structure) 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 Design Patterns Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.