1. Chapter 9 Behavioral Design Patterns

2. Process Phase Affected by 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. Design Purpose Interpret expressions written in a formal grammar. Design Pattern Summary Represent the grammar using a Recursive design pattern form: Pass interpretation to aggregated objects. Interpreter Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

4. Interpreter Client Interface AbstractExpression interpret() Client Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

5. Interpreter Design Pattern AbstractExpression interpret() Client TerminalExpression interpret() NonTerminalExpression interpret() 1..n Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

6. interpret() Interpreter Sequence Diagram TerminalExpression :NonterminalExpression :Client AbstractExpression NonterminalExpression... create & interpret() create & interpret()... Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

7. Example of a Virtual Machine “Program” 260Mhz & 64MB 400Mhz & 128MB 260Mhz & 32MB assemble …. Graphics reproduced with permission from Corel. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

8. Input For Network Assembly Example Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

9. Output of Network Assembly Example (1 of 3) Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

10. Output of Network Assembly Example (2 of 3) Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

11. Output of Network Assembly Example (3 of 3) Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

12. Design Goal At Work:  Flexibility, Correctness, Reuse  Separate the processing of each part of the network order. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

13. Interpreter Design Pattern Component assemble() NetSystem assemble() component1 Client Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

14. Application of Interpreter Design Pattern Component assemble() Computer assemble() NetSystem assemble() component1 component2 RAM describe() CPU describe() cpu ram Client Setup getInputFromUser() parse() 1 0..1 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

15. Key Concept:  Interpreter Design Pattern  -- a form for parsing and a means of processing expressions. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

16.  - given a collection of objects e.g., o the videos in a video store o a directory  - having specified ways to progress through them e.g., o “list in alphabetical order” o “list all videos currently on loan” ... encapsulate each of these ways Aggregate object Purpose of Iterator iterator2 iterator7 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

17. Design Purpose (Gamma et al) Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation. Design Pattern Summary Encapsulate the iteration in a class pointing (in effect) to an element of the aggregate. Iterator Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

18. Using Iterator Functions /* To perform desiredOperation() on elements of the aggregate according to the iteration (order) i : */ for( i.setToFirst(); !i.isDone(); i.increment() ) desiredOperation( i.getCurrentElement() ); Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

19. Functions for Iterator // Iterator "points" to first element: void setToFirst(); // true if iterator "points" past the last element: boolean isDone(); // Causes the iterator to point to its next element: void increment(); // Return the element pointed to by the iterator: C getCurrentElement(); Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

20. Iterator Operations Set to beginning Increment Get current element Check not done yet The Iterator Index (integer) i on array myArray i = 0++imyArray[ i ] i < myArray.length Index (integer) j on Vector myVector j = 0++j myVector.get( j ) j < myVector.size() Iterator (object) myIterator.setToFirst() myIterator.increment() myIterator.getCurrent Element() ! myIterator.isDone() Iterator in Arrays, Vector, and in General Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

21. Imagining Iterator iterator: Iterator element: Element Aggregate of Element objects Key: Intended sequence of Element objects After first() executes, iterator references this object. After increment() executes, iterator references this object. Before increment() executes, iterator references this object. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

22. Iterator Example Setup Code // Suppose that we have iterators for forward and // backward order: we can re-use print_employees() List employees = new List(); ForwardListIterator fwd // to go from front to back = new ForwardListIterator ( employees ); ReverseListIterator bckwd // to go from back to front = new ReverseListIterator ( employees ); client.print_employees( fwd ); // print from front to back client.print_employees( bckwd ); // print from back to front Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

23. Iterator Class Model Aggregate Client Iterator setToFirst() increment() isDone() getCurrentItem() ConcreteIteratorConcreteAggregate AggregatedElement 1…n 1 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

24. An Organizational Chart Example Vanna Presley vice president, 4 years Sue Miller svce. mgr., 7 years Sam Markham svce. mgr., 5 years Sal Monahan svce. mgr., 1 year Iolanthe Carp ind. contrib., 8 Inge Carlson ind. contrib., 12 Inez Clapp ind. contrib., 11 Inky Conway ind. contrib., 6 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

25. Iterating by Organizational Seniority Over a Bank Organization Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

26. Iterating by Years of Service Over an Organization Chart Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

27. Design Goal At Work:  Flexibility, Correctness  Separate the “visiting” procedure from the processing of individual employees. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

28. Class Structure for Iterator Example ServiceIterator OrgSeniorityIterator OrgChartDP OrgChartIteratorDP Teller Employee display() Supervisor ClientSetup OrgChartIterator first() next() isDone() currentItem() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

29. Computing next() root 1 45 6 9 10 23 78 11 12 ( 1, 2, 0, 0 ) // my distance from the end of my sibling list ) DeepRoot doneNode ( 1 )( 0 ) Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

30. main() Sequence Diagram for Encounter Foreign Character Use Case User Employee display( OrgCharIterator ) display() first(), next(), idDone(), getItem() etc. Employee OrgChartIterator:Client AlphabeticalOrgChartIterator :Setup Get org chart as in Composite example tbd getTheIterator() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

31. Computing next() root 1 45 6 9 10 23 78 1112 ( 1, 2, 0, 0 ) DeepRoot doneNode ( 1 ) ( 0 ) “distance from the end of my sibling list” ( 1, 2, 0 ) ( 1, 2 ) Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

32. main() Iterator Example Sequence Diagram User Employee display( OrgCharIterator ) display() first(), next(), isDone(), getItem() etc. Employee OrgChartIterator :Client AlphabeticalOrgChartIterator:Setup Get org chart as in Composite example tbd getTheIterator() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

33. Iterator in the Java API Collection Iterator iterator() Iterator next() hasNext() remove() ListIteratorListAbstractCollection AbstractList ListIterator listIterator() Iter* ListItr* * IBM implementation ArrayListVector Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

34. Output for Iteration on a Java ArrayList Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

35. Address Book Application Using Java Iterator Collection Iterator iterator() Iterator next() hasNext() remove() ListIterator List AbstractList ListIterator listIterator() ListItr* ArrayList NameAddrEntryAddressBook 0..n This application Key: Java API Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

36. Iterator Class Model ConcreteIterator Client Aggregate createIterator( ) Iterator setToFirst() increment() isDone() getCurrentItem() ConcreteAggregate createIterator( ) return new ConcreteIterator( this ); OLD Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

37. Output for StringTokenizer Example Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

38. Key Concept:  Iterator Design Pattern  -- to access the elements of a collection. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

39. Solicitation of Customer Information 1 of 2 Name and Location Basic information Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

40. Solicitation of Customer Information 2 of 2 Account Information Additional information Customer ID Total business Amount due Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

41. Design Purpose Avoid references between dependent objects. Design Pattern Summary Capture mutual behavior in a separate class. Mediator Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

42. The Mediator Class Model MediatorColleague ConcreteMediator ConcreteColleague1ConcreteColleague2 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

43. :ConcreteMediator :ConcreteColleague1:ConcreteColleague2 :Mediator 2. Initiation on a ConcreteColleague doPart1() doPart2() 1. Initiation by ConcreteMediator mediate() doSome1() doSome2() Mediator Sequence Diagrams Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

44. Design Goal At Work:  Reusability and Robustness  Avoid hard-coded dependencies among the game’s GUI classes, enabling their use in other contexts. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

45. Application of Mediator To Customer Information Application CustomerDisplay :BasicInfoGUI: CustomerGUI :CustTypeDisplay:CustInfoDisplay Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

46. The Mediator Class Model in the Java API ComponentListener actionPerformed() Component addComponentListener() MyEventListener MyComponent1MyComponent2 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

47. Key Concept:  Mediator Design Pattern  -- to capture mutual behavior without direct dependency. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

48. Design Purpose Arrange for a set of objects to be affected by a single object. Design Pattern Summary The single object aggregates the set, calling a method with a fixed name on each member. Observer Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

49. Observer Design Pattern Source notify() Observer update() for all Observer’s o: o.update(); Client of this system 1 2 1..n Server partClient part Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

50. Observer Design Pattern Source notify() Observer update() ConcreteSource state ConcreteObserver observerState update() for all Observer’s o: o.update(); Client 2 3 1..n Server partClient part 1 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

51. Observer Applied to International Hamburger Co. Source notify() Observer update() Headquarters demand SeniorManagement forecast update() Client 1..n Marketing marketingDemand update() doDisplay() if( abs( hq.demand - marketingDemand ) > 0.01 ) {marketingDemand = hq.getDemand(); doDisplay(); } Server partClient part Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

52. I/O Example for Mutual Fund Observer Example Note: HiGrowthMutualFund starts with 3 shares of Awesome, assumes price of 1.0, and has non-Awesome holdings totalling 400.0 Note: MedGrowthMutualFund starts with 2 shares of Awesome, assumes price of 1.0, and has non-Awesome holdings totalling 300.0 Note: LoGrowthMutualFund starts with 1 shares of Awesome, assumes price of 1.0, and has non-Awesome holdings totalling 200.0 Enter 'quit': Any other input to continue. go on Enter the current price of Awesome Inc. in decimal form. 32.1 Value of Lo Growth Mutual Fund changed from 201.0 to 232.1 Value of Med Growth Mutual Fund changed from 302.0 to 364.2 Value of Hi Growth Mutual Fund changed from 403.0 to 496.3 Enter 'quit': Any other input to continue. go on Enter the current price of Awesome Inc. in decimal form. 21.0 Value of Lo Growth Mutual Fund changed from 232.1 to 221.0 Value of Med Growth Mutual Fund changed from 364.2 to 342.0 Value of Hi Growth Mutual Fund changed from 496.3 to 463.0 Enter 'quit': Any other input to continue. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

53. Design Goal At Work:  Flexibility  Allow mutual funds objects to easily acquire or divest of stocks. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

54. Observable notifyObservers() Observer update( Observable, Object ) AwesomeInc price LongTermMutualFund …. update(…) Observer Example: Mutual Funds Key: Developer Class Java API Class MediumTermMutualFund …. update(…) HiGrowthMutualFund …. update(…) MutualFund value numAwesomeShares Client Setup Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

55. Observable notifyObservers() Observer update( Observable, Object ) MyObservable MyConcreteObserver observerState update(…) Observer in the Java API subject Key: Developer Class Java API Class Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

56. Key Concept:  Observer Design Pattern  -- to keep a set of objects up to date with the state of a designated object. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

57. Design Purpose Cause an object to behave in a manner determined by its state. Design Pattern Summary Aggregate a State object and delegate behavior to it. State Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

58. TargetStateB handleRequest() Target doRequest() State Design Pattern Structure: doRequest() behaves according to state of Target targetState TargetState handleRequest() Client TargetStateA handleRequest() 1 { targetState.handleRequest(); }... Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

59. GUI For a Role-Playing Video Game Set Characteristics Courtesy Tom VanCourt and Corel Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

60. Design Goal At Work:  Correctness and Reusability  Separate the generic code for handling button clicks from the actions which depend on the game’s status at the time. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

61. State Design Pattern Applied to Role-Playing Game MyGame setCharacteristics() MyGameState handleClick() state { state.handleClick(); } Engaging handleClick() SettingUp handleClick() Waiting handleClick() SettingCharacteristics handleClick() { showWindow(); …. // more } { showWindow(); …. // more } { // already responding … // display message } { // do nothing … // display message } Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

62. Key Concept:  State Design Pattern  -- to cause a object’s functions to behave according to the state it’s in. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

63. Design Purpose Allow a set of objects to service a request. Present clients with a simple interface. Design Pattern Summary Link the objects in a chain via aggregation, allowing each to perform some of the responsibility, passing the request along. Chain of Responsibility Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

64. Chain of Responsibility: Object Model entryHandler:HandlerSubclassX (next element): HandlerSubclassY (next element): HandlerSubclassZ successor Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

65. HandlerSubclassA handleRequest() respondA() Chain of Responsibility Class Model Client HandlerSubclassB handleRequest() respondB() successor Handler handleRequest() respondA(); // handle some of the required functionality successor.handleRequest(); // pass along remaining responsibility.. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

66. GUI For Customer Information Application Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

67. Output for Customer Information Application Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

68. Design Goal At Work:  Flexibility  Isolate the responsibilities of each part of the input form to generate its XML. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

69. Class Model For User Information Collection CustomerInfoElement CustomerNameCompanyNameCustomerInfo CustomerPersonalCustomerProfessionalCustomerAddressCompany container TextFieldListener «client» CustomerInfoApp «setup» Each of these classes supports handleClick() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

70. Object Model Fragment for Customer Information Example : CompanyName :Company :CustomerProfessional container :CustomerInfo handleClick() container handleClick() container handleClick() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

71. Key Concept:  Chain of Responsibility Design Pattern  -- to distribute functional responsibility among a collection of objects. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

72. Design Purpose Increase flexibility in calling for a service e.g., allow undo-able operations. Design Pattern Summary Capture operations as classes. Command Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

73. Target1 action1() The Command Design Pattern Action2Command execute() Target2 action2() replaced Command execute() Action1Command execute() Client Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

74. The Command Design Pattern: Example MenuItem handleClick() Command execute() CutCommand execute() Document cut() copy() document command CopyCommand execute() document document.cut() document.copy() command.execute() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

75. execute() Sequence Diagram for Document Command Example :MenuItem handleClick() command : Command :CopyCommand document :Document copy() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

76. I/O for Word Processor Undo Example 1 of 2 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

77. I/O for Word Processor Undo Example 2 of 2 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

78. Design Goal At Work:  Flexibility and Robustness  Isolate the responsibilities of the Word Processor commands, making them save-able and reversible. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

79. Undo Example Class Model WordProcessor Command execute() undo() CutCommand textCut: String offset: int execute() undo() Document text: String commandHistory PasteCommand offset: int length: int execute() undo() 0..n QuitCommand execute() UndoCommand execute() document DocumentCommand getInputFromUser() document Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

80. Key Concept:  Command Design Pattern  -- to avoid calling a method directly (e.g., so as to record or intercept it). Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

81. Required to solve equations of the form ax 2 + bx + c = 0. Must be able to handle all input possibilities for a, b, and c. This is a tutorial application that must provide full explanations to users about the solutions for all values for a, b, and c. Example of Template Motivation Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

82. 1.Report progress 2.Display number of solutions 3.Display first solution, if any 4.Display second solution, if any A Basic Quadratic Algorithm Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

83. Design Purpose Allow runtime variants on an algorithm. Design Pattern Summary Express the basic algorithm in a base class, using method calls where variation is required. Template Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

84. Class Model for Template TemplateAlgorithm handleRequest() nonInheritedMethod() calledMethod1() calledMethod2() …. Algorithm1 calledMethod1() calledMethod2() …. algorithm Algorithm3 calledMethod1() calledMethod2() …. Client Algorithm2 calledMethod1() calledMethod2() …. { algorithm.handleRequest(); } Subject doRequest() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

85. I/O For Quadratic Example 1/2 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

86. I/O For Quadratic Example 2/2 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

87. displaySolutions() { displayWhatsHappening(); displayNumSolutions(); displayFirstSolutions(); displaySecondSolution(); } Quadratic Display Algorithm Override Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

88. Design Goal At Work:  Flexibility and Robustness  Isolate the main algorithm for quadratic solution display. Isolate the variants that depend on the coefficients. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

89. NoSolutions displayNumSolutions() displayFirstSolution() displaySecondSolution() OneSolution displayNumSolutions() displayFirstSolution() displaySecondSolution() Class Model for Quadratic Problem QuadraticEquation float a, b, c solveQuadratic() QuadraticAlgorithm displayWhatsHappening() displaySolution() inputMakesSense() displayNumSolutions(); displayFirstSolution() displaySecondSolution() algorithm TwoSolutions displayNumSolutions() displayFirstSolution() displaySecondSolution() Client { algorithm.displaySolution(); } Setup getABC() InfinitelyManySolutions displayNumSolutions() displayFirstSolution() displaySecondSolution() Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

90. Key Concept:  Template Design Pattern  -- to capture a basic algorithm and its variants. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

91. Behavioral Design Pattern s capture behavior among objects o Interpreter handles expressions in grammers o Iterator visits members of a collection o Mediator captures behavior among peer objects o Observer updates objects affected by a single object o State allows method behavior to depend on current status o Chain of Responsibility allows a set of objects to provide functionality collectively o Command captures function flexibly (e.g. undo-able) o Template captures basic algorithms, allowing variability Summary of Behavioral Patterns Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.