Chapter 8 Structural Design Patterns

1. Chapter 8Structural Design Patterns

2. Process Phases Discussed in This Chapter Requirements Analysis Design Framework Architecture Detailed Design Implementation Key: = main emphasis = secondary emphasis x x Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

3. Facade 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. 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 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 Customer getCustomerName() getNumAccounts() getPersonalNote() getAccount( int ) Account getAccountNum() deposit( int ) getBalance() AccountException CustomerException framework 1..n BankCustomer BankAccount IntroMessage «facade» BankCustomers doDeposit( 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. Output of Façade Banking Example Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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

11. Decorator Design Purpose 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 Substance doAction() Decoration doAction() objDecorated 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.

13. Linked Objects in Decorator client:Client decoration1:Decoration decoration1.objectDecorated:Decoration … :Decoration ….:Substance 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. Output of Customer/Account Example Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

16. Decorator Applied to Customer / Accounts Example AttemptToAddBadBankingComponentException BankingComponent add( Component ) describe() 1 Client nextComponent Setup Customer describe() Account describe() 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.

17. Use of Decorator in java.io Reader 1 InputStreamReader BufferedReader InputStream Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

18. java.ioDecorator example : BufferedStreamReader :InputStreamReader System.in:InputStream Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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

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 non-leaf node 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() LeafNode doIt() NonLeafNode doIt() component TypeANonLeafNode doIt() TypeBNonLeafNode doIt() etc. 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 nonLeaf1ChildX :NonLeafNode :LeafNode 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 1..n Employee stateName() Client reports Clerk stateName() Teller stateName() Supervisor add(Employee) Setup Manager stateName() President stateName() 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. Output of Bank/Teller Example Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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

30. Attempt to Simplify Composite children Component 0…n Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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

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

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

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

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

36. Adapter Design Pattern Application Adaptation Legacy system Financial amount() Principle computeValue() Client Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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

38. Adapter Example: Inheritance Version AbstractClass standinForRequiredMethod() RequiredClass requiredMethod() Client Adapter standinForRequiredMethod() { requiredMethod();} Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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

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

41. Flyweight Class Model Client Flyweight 1..n Flyweight doAction(Context) FlyweightFactory getFlyweight(Characteristic) ConcreteFlyweight doAction(Context) Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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

43. Flyweight Example: Text Magnifier Input ABBRA CADABBRAA ARE THE FIRST TWO OF MANY WORDS IN THIS FILE … 1 Input color: RED ….. Starting character: 2 … Ending character: 3 2 Output . . . . . . Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

44. When Space is No Limitation:Linked BigCharacter Objects A1:BigACharacter color “red” letter “o”… B1:BigBCharacter color == “red” … B1:BigBCharacter color “red” letter “v”… A1:BigACharacter color == “black” … B2:BigBCharacter color “black” letter “v”… R1:BigRCharacter color “black” letter “x”… A2:BigACharacter color “black” letter “o”… Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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

46. Mapping “A”, “B” etc. to a BigABigB etc. object Client Responsibilities DP Responsibilities Use string to determine which flyweight . Use color information to form the context (parameter value). Make (shared) BigA, BigB, … flyweightobject available to clients ABBRA CADABBRA … color “RED” begins 0 … Flyweights (1 each) bigA:BigA getMatrix( ”red” ) Line for output bigB:BigB . . . . . . getMatrix( “black” ) Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

47. Typical Output For Large Type Example Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

48. BigCharacter Flyweight Application: Class Model PagePrinter Application of Flyweight BigChar constructionChar getMatrix( String color ) 26 BigCharFactory getFlyweight( char ) «singleton» BigA «singleton» BigB Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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

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