1. Chapter 6 Introduction to Design Patterns

2. Process Phase Discussed in This Chapter Requirements Analysis Design Implementation ArchitectureFrameworkDetailed Design x Key:= secondary emphasis x = main emphasis 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 o Reuse flexible designs o Keep code at a general level o Minimize dependency on other classes  Robustness o Reuse reliable designs o Reuse robust parts  Sufficiency / Correctness o Modularize design o Reuse trusted parts Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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

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

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

7. KitchenViewer Without Design Patterns Kitchen Client renderKitchen() FloorCabinet ModernWallCabinet ModernFloorCabinetAntiqueFloorCabinet AntiqueWallCabinet WallCabinet 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. AntiqueKStyle getWallCabinet() getFloorCabinet() The Abstract Factory Idea KitchenStyle getWallCabinet() getFloorCabinet() ModernKStyle getWallCabinet() getFloorCabinet() WallCabinetFloorCabinet AntiqueWallCabinetAntiqueFloorCabinet FloorCabinet getFloorCabinet() { return new AntiqueFloorCabinet(); } …… FloorCabinet getFloorCabinet() { return new ModernFloorCabinet(); } Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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

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

12. Abstract Factory Design Pattern Alternative Style getComponentA() getComponentB() Client doOperation() Style1 getComponentA() getComponentB() Style2 getComponentA() getComponentB() ComponentAComponentB Style1ComponentA Style1ComponentB Style2ComponentA Style2ComponentB Collection getComponentA() getComponentB() 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 berth to drydock  obstacles 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. ShipTugboat 1..n1 Harbor application Customs application: reuse Ship alone ShipLongshoreman  Avoiding Dependencies 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 Tugboat LeavingPort estimateTime() 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 ShipTugboat Vessel PortMission estimateTime() LeavingPort estimateTime() EnteringPort estimateTime() BeingMaintained estimateTime() Mediator base class Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

21. You have requested to view a luxury model with luxury body style, and black body color. Model Body Style Body color Choose an automobile to view. OK A Design Problem Solvable by Chain of Responsibility BasicMidsize Luxury SUV Luxury Extra Basic Black Brown Red White This part is fixed Display depends on model selected Display depends on body style selected Assume that each of these will eventually be a small, expensive animation. 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 1.Static : class model (building blocks) 2.Dynamic : sequence or state diagram (operation)  Levels – decomposition of patterns 1.Abstract level describes the core of the pattern 2.Concrete (= non abstract) level describes the particulars of this case  Roles – the “players” in pattern usage 1.Application of the design pattern itself 2.Clients of the design pattern application 3.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 1. Client role 2. Setup role A C A. Static viewpointB. Dynamic viewpoint 3. Role: Application of the design pattern D B (i) Abstract level (ii) Concrete level (class model) (sequence or state diagram) (class or classes) : Reference direction Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

25. getWallCabinet() Abstract Factory Application Sequence Diagram myStyle :KitchenStyle Client myStyle: ModernKStyle myStyle: AntiqueKStyle renderKitchen ( myStyle ) wallCabinet1: ModernWallCabinet wallCabinet1: AntiqueWallCabinet ModernWallCabinet() getWallCabinet() AntiqueWallCabinet() myStyle. getWallCabinet() -- IF myStyle BELONGS TO ModernKStyle -- -- IF myStyle BELONGS TO AntiqueKStyle -- 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 KitchenStyle Kitchen Client ModernKStyle AntiqueKStyle WallCabinet FloorCabinet ModernWallCabinet ModernFloorCabinet AntiqueWallCabinet AntiqueFloorCabinet Abstract level Concrete level 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. 2. Client Role1. Design Pattern Application Interface to the pattern (frequently abstract; possibly several classes) DPClient DPInterface Rest of the design pattern application Interacts with the design pattern only through its interface 3. Setup Role The Three Roles Involved in Design Pattern Usage Rest of the Application No limitations 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 requiredFunction() … intermediaryFunction( … ) { … requiredFunction() … } Client clientFunction() intermediaryFunction() replace  … clientFunction( … ) { … intermediaryFunction( … ) … } Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

34. Basic Design Pattern Form #1: Delegation DoerBase doIt() DPInterface interfaceMethod() ConcreteDoer1 doIt() ConcreteDoer2 doIt()... doerObject … interfaceMethod( … ) { … doerObject.doIt() … } Client 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() NonrecursiveClass doOperation() RecursiveClass doOperation() void doOperation( … ) { … aggregate … } aggregate Client 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() IndividualContributor printOrganization() Supervisor printOrganization() void printOrganization( … ) { … supervisees.printOrganization() … } supervisees Client 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 o Typically class models and sequence diagrams respectively  Use of a pattern application is a Client Role o Client interface carefully controlled o “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 Source notify() Observer update() ConcreteSubject state ConcreteObserver observerState update() Trigger 1..n Initialize Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.