Chapter 6 Introduction to Design Patterns

1. Chapter 6Introduction to Design Patterns

2. Process Phase 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. Sample Design Goals and Ways to Accomplish Them • Reusability, Flexibility, and Maintainability • 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.

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

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

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

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

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

9. The Abstract Factory Idea KitchenStyle getWallCabinet() getFloorCabinet() WallCabinet FloorCabinet … AntiqueWallCabinet … AntiqueFloorCabinet 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.

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

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

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

13. Key Concept: Design Pattern -- class combination and algorithm fulfilling a common design purpose. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

14. Key Concept: Creational Design Patterns -- 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.

15. Key Concept: Structural Design Patterns -- used to represent data structures such as trees, with uniform processing interfaces. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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

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

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

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

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

21. A Design Problem Solvable by Chain of Responsibility Choose an automobile to view. This part is fixed Model Basic Midsize SUV Luxury Display depends on model selected Body Style Basic Extra Luxury Display depends on body style selected Body color Black Brown Red White Assume that each of these will eventually be a small, expensive animation. You have requested to view a luxury model with luxury body style, and black body color. OK Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

22. Key Concept: Behavioral Design Patterns -- to capture behavior among objects. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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

24. Characteristics of Design Patterns 2 (class or classes) 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.

25. Abstract Factory Application Sequence Diagram Client myStyle:KitchenStyle myStyle. getWallCabinet() -- IF myStyle BELONGS TO ModernKStyle -- myStyle: ModernKStyle wallCabinet1: ModernWallCabinet renderKitchen ( myStyle ) getWallCabinet() ModernWallCabinet() -- IF myStyle BELONGS TO AntiqueKStyle -- myStyle: AntiqueKStyle wallCabinet1: AntiqueWallCabinet getWallCabinet() AntiqueWallCabinet() 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. 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.

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

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

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

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

32. Key Concept: Three Roles A part of a design either 1) applies a design pattern, 2) is a client of the pattern application, or 3) re/initializes these. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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

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

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

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

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

38. Summary of This Chapter • Design Patterns are recurring designs satisfying recurring design purposes • 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 usually Delegation or Recursion • Classified as Creational, Structural, or Behavioral Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

39. Observer Design Pattern Trigger 1..n Observer update() Source notify() Initialize ConcreteObserver observerState update() ConcreteSubject state Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.