1 / 41

Chapter 6 Introduction to Design Patterns

Chapter 6 Introduction to Design Patterns. Sample Design Goals and Ways to Accomplish Them. Reusability, Flexibility, and Efficiency Reuse flexible designs Keep code at a general level Minimize dependency on other classes Robustness Reuse reliable designs Reuse robust parts

davin
Download Presentation

Chapter 6 Introduction to 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 6Introduction to Design Patterns

  2. Sample Design Goals and Ways to Accomplish Them • Reusability, Flexibility, and Efficiency • Reuse flexible designs • Keep code at a general level • Minimize dependency on other classes • Robustness • Reuse reliable designs • Reuse robust parts • Sufficiency / Correctness • Modularize design • Reuse trusted parts Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  3. Key Concept: Design Pattern A design pattern is a combination of classes and accompanying algorithms that fulfill a common design purpose. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  4. 6.1 - Categories of Design Patterns

  5. Key Concept: Creational Design Patterns • Factory • Abstract Factory • Prototype • Singleton -- used to create objects in flexible or constrained ways. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  6. Key Concept: Structural Design Patterns -- used to represent data structures such as linked lists or trees, with uniform processing interfaces. • Composite • Decorator • Adapter • Facade • Flyweight • Proxy Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  7. Key Concept: Behavioral Design Patterns -- used to capture behavior among objects. • Chain of Responsibility • Command • Interpreter • Mediator • Observer • State • Template • Iterator Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  8. Abstract Factory 6.2 - Example Use of a Creational Design Pattern

  9. KitchenViewer Interface Wall cabinet menu  Counter display area styles Floor cabinet Modern Classic Antique Arts & Crafts Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  10. KitchenViewer Example Wall cabinets Floor cabinets Countertop Modern Classic Antique Arts & Crafts Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  11. Selecting Antique Style Modern Classic Antique Arts & Crafts Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  12. KitchenViewer Without Design Patterns Client renderKitchen() Kitchen WallCabinet FloorCabinet ModernWallCabinet AntiqueWallCabinet AntiqueFloorCabinet ModernFloorCabinet Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  13. Design Goal At Work: Flexibility Our design should be flexible enough to produce any of several kitchen styles. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  14. The Abstract Factory Idea A design class WallCabinet FloorCabinet KitchenStyle getWallCabinet() getFloorCabinet() AntiqueFloorCabinet … AntiqueWallCabinet … ModernKStyle getWallCabinet() getFloorCabinet() AntiqueKStyle getWallCabinet() getFloorCabinet() FloorCabinet getFloorCabinet() { return new ModernFloorCabinet(); } FloorCabinet getFloorCabinet() { return new AntiqueFloorCabinet(); } Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  15. Abstract Factory Design Pattern Applied to KitchenViewer Client renderKitchen( KitchenStyle ) KitchenStyle getWallCabinet() getFloorCabinet() Kitchen getWallCabinet() getFloorcabinet() WallCabinet FloorCabinet ModernWallCabinet ModernKStyle getWallCabinet() getFloorCabinet() AntiqueWallCabinet ModernFloorCabinet AntiqueKStyle getWallCabinet() getFloorCabinet() AntiqueFloorCabinet Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  16. Example of Code inside renderKitchen(KitchenStyle myStyle) // Create the wall cabinets; type is determined by the class of myStyle WallCabinet wallCabinet1 = myStyle.getWallCabinet(); WallCabinet wallCabinet2 = myStyle.getWallCabinet(); // Create the floor cabinets; type determined by the class of myStyle FloorCabinet floorCabinet1 = myStyle.getFloorCabinet(); FloorCabinet floorCabinet2 = myStyle.getFloorCabinet(); // Create the kitchen object (in the style required) Kitchen kitchen = new Kitchen(); kitchen.add(wallCabinet1, . . .); kitchen.add(wallCabinet2, . . .); . . . kitchen.add(floorCabinet1, . . .); kitchen.add(floorCabinet2, . . .); . . .

  17. Abstract Factory Design Pattern Client doOperation( Style myStyle ) Style getComponentA() getComponentB() Collection ComponentA ComponentB Style1ComponentA Style1 getComponentA() getComponentB() Style2ComponentA Style1ComponentB Style2 getComponentA() getComponentB() Style2ComponentB Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  18. Abstract Factory Design PatternAlternative Client doOperation() Collection getComponentA() getComponentB() Style getComponentA() getComponentB() ComponentA ComponentB Style1ComponentA Style1 getComponentA() getComponentB() Style2ComponentA Style1ComponentB Style2 getComponentA() getComponentB() Style2ComponentB Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  19. Mediator 6.3 - Example Use of a Behavioral Design Pattern

  20. Example of Behavioral Design Goal: Port Traffic obstacles to drydock  berth berth Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  21. Avoiding Dependencies  Harbor application 1 1..n Ship Tugboat A customs application: reuses Ship alone Ship Longshoreman Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  22. Mediator Concept Applied to The Harbor Problem Ship LeavingPort estimateTime() Tugboat Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  23. Applying the Mediator Design Pattern to The Harbor Problem PortMission estimateTime() Vessel Mediator base class Ship Tugboat EnteringPort estimateTime() LeavingPort estimateTime() BeingMaintained estimateTime() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  24. 6.4 - Characteristics of Design Patterns

  25. Characteristics of Design Patterns 1 • Viewpoints – ways to describe patterns • Static: class model (building blocks) • Dynamic: sequence or state diagram (operation) • Levels – decomposition of patterns • Abstract level describes the core of the pattern • Concrete (= non abstract) level describes the particulars of this case • Roles –the “players” in pattern usage • Application of the design pattern itself • Clients of the design pattern application • Setup code initializes and controls Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  26. Key Concept: Two Viewpoints We consider design patterns from the static viewpoint (what they are made from) and the dynamic viewpoint (how they function). Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  27. (class or classes) Characteristics of Design Patterns 2 1. Client role 3. Role: Application of the design pattern A. Static viewpoint B. Dynamic viewpoint A B (i) Abstract level (ii) Concrete level C D (sequence or state diagram) (class model) 2. Setup role : Reference direction (class or classes) Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  28. Key Concept: Two Levels Design patterns usually have an abstract level and a non-abstract (“concrete”) level. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  29. Concrete and Abstract Layers Client WallCabinet KitchenStyle FloorCabinet Abstract level Concrete level Kitchen ModernWallCabinet AntiqueWallCabinet ModernKStyle ModernFloorCabinet AntiqueKStyle AntiqueFloorCabinet Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  30. Design Goal At Work: Correctness We want to provide an interface to a design pattern so that its functionality is clear and separate. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  31. Key Concept: Three Roles Each part of a design pattern fills one of three roles: Applies (i.e., instantiates) the design pattern, or is a client of the pattern application, or reinitializes or sets up the two previous roles Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  32. Design Goal At Work: Correctness To use design patterns effectively, we distinguish the roles involved. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  33. The Three Roles Involved in Design Pattern Usage 2. Client Role 1. Design Pattern Application Interacts with the design pattern only through its interface Interface to the pattern (frequently abstract; possibly several classes) DPInterface DPClient 3. Setup Role No limitations Rest of the design pattern application Rest of the Application DP = Design Pattern Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  34. 6.5 - Forms of Design Patterns

  35. Design Pattern Forms -- Forms represent patterns to the design patterns (i.e., metapatterns) -- They consist of delegation forms and recursion forms Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  36. Basic Idea of Delegation … intermediaryFunction( … ) { … requiredFunction() … } … clientFunction( … ) { … intermediaryFunction( … ) … } Client clientFunction() intermediaryFunction()  replace requiredFunction() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  37. Basic Design Pattern Form #1: Delegation Client … interfaceMethod( … ) { … doerObject.doIt() … } doerObject DoerBase doIt() DPInterface interfaceMethod() ConcreteDoer1 doIt() ConcreteDoer2 doIt() . . . Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  38. Basic Design Pattern Form #2: Recursion RecursionBase doOperation() Client aggregate NonrecursiveClass doOperation() RecursiveClass doOperation() void doOperation( … ) { … aggregate … } Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  39. The Recursion Form Applied to an Organization Chart Employee printOrganization() Client supervisees IndividualContributor printOrganization() Supervisor printOrganization() void printOrganization( … ) { … supervisees.printOrganization() … } Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  40. Key Concept: Two Forms A design pattern’s form is usually either a delegation of responsibility or a class that relates to itself (recursion). Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

  41. Summary of This Chapter • Design Patterns are recurring designs satisfying recurring design purposes • Classified as Creational, Structural, or Behavioral Described by Static and Dynamic Viewpoints • Typically class models and sequence diagrams respectively • Use of a pattern application is a Client Role • Client interface carefully controlled • “Setup,” typically initialization, a separate role • Design patterns Forms are Delegation or Recursion  Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

More Related