1 / 54

Chapter 8 Structural Design Patterns

Chapter 8 Structural Design Patterns. Facade Decorator Composite Adapter Flyweight Proxy. Façade Design Pattern. Facade. Design Purpose. Provide an interface to a package of classes. Design Pattern Summary.

mauve
Télécharger la présentation

Chapter 8 Structural Design Patterns

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. Façade Design Pattern

  3. Facade 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. 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 <<interface>> <<interface>> Customer getCustomerName() getNumAccounts() getPersonalNote() getAccount( int ) Account getAccountNum() deposit( int ) getBalance() AccountException CustomerException framework 1..n BankCustomer BankAccount IntroMessage package «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. 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. 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 Undecorated class 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 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 <<interface>> Means exactly one aggregate per account BankingComponent add( Component ) describe() 1 Client nextComponent Setup Customer describe() Account 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 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. Composite Design Pattern Bank/Teller Example 1..n Employee stateName() Client reports Clerk stateName() Teller stateName() Supervisor add(Employee) Setup Manager stateName() President 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 Application Adaptation Legacy system 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.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. 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 <<abstract>> 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.expensiveMethod(); } 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 > all > middle > all Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

More Related