What We’ve Covered in CSE 432/533

1. What We’ve Covered in CSE 432/533 • 25 specific GoF/PH design patterns’ structure & content • How requirements, design forces, and patterns interact • Understanding pattern similarities and differences • Adapter vs. Bridge, Strategy vs. Template Method • Mediator vs. Observer, etc. • Using patterns in specific design scenarios • Chapters 2, 3 in the Pattern Hatching text book • A number of (sometimes common) cases in your projects • A good way to build design intuition, remember applicability • Pattern combinations lead to small pattern languages • E.g., Command + memento + strategy (undoing commands) • E.g., Composite + visitor + iterator (modify a structure) • Remember combinations you find useful, for future reference

2. Design Pattern Characteristics and Use • A pattern has a name • e.g., the Command pattern • A pattern documents a recurring problem • Design forces that constrain the solution space • e.g., Issuing requests to objects without knowing in advance what’s to be requested or of what object • A pattern is applied in a design context • Other criteria and details that shape design decisions • Other design forces that constrain the solution space • A pattern describes the core of a solution • e.g., class roles, relationships, and interactions • Important: this is different than describing a design • A pattern considers consequences of its use • Trade-offs, unresolved forces, other patterns to use

3. Simple Pattern Form Example: “Singleton” • Problem • Want to ensure a single instance of a class, shared by all uses throughout a program • Context • Need to address initialization versus usage ordering • Solution • Provide a global access method (e.g., via a static member function in C++) • First use of the access method instantiates the class • Constructors for instance can be made private • Consequences • Object is never created if it’s never used • Object is shared efficiently among all uses • Can free you from passing a parameter all over a program

4. Pattern-Oriented Software Design & Development • We’ve looked at a lot of patterns’ details this semester • 23 (GoF) + 2 (PH) Design Patterns • Including Generation Gap, Typed Message • However, the key ideas they embody are what matter • Patterns capture reusable design expertise • Patterns bridge between requirements and design • Patterns interact with other patterns non-trivially • Good pattern combinations yield solid designs • Corollary: Booch’s observation about pattern richness • Unsuccessful combinations leave forces unresolved • As a design evolves, forces (and relevant patterns) change

5. Requirements  Design Forces  Patterns • Requirements are declarative • what your software will do, provide, etc. • the way in which your software will do something • E.g., support different games’ collections of cards • Design forces are descriptive and prescriptive • Identify circumstances/issues to be considered • Constrain set of designs within a concrete context • Requirements, other patterns shape the context • Patterns are normative and generative • Resolve design forces in standardized ways • Have consequences that may then need resolution • Guide toward a single design, but don’t specify it

6. Scenarios are Guides to Pattern Use: E.g., Undo • Client performs action, undo stack remembers • Undo call executes top command on stack • Command restores previous state (LIFO) Client System UndoCommand UndoStack action remember construct time store / / / / / / / / undo restore execute

7. Patterns are Made to be Combined • Diagram below is from the “Pattern Hatching” text, page 29 in my copy • Node class plays roles in both of the patterns, joins them • Component role in Composite, Subject role in Proxy • Such “Alexandrian Density” can have both good and bad implications • Resolution of multiple concerns (elegant) vs. tangling of concerns (brittle)

8. Pattern Combinations  Mini Pattern Languages • Some operations don’t have a closed form inverse • Memento can remember state prior to command use • Strategy supports both kinds of Command inverses Client System UndoCommand UndoStack action remember construct time store / / / / / / / / undo restore execute

9. Advice: Re-Read PH and GoF Books Repeatedly • GoF text introduces patterns, provides a detailed reference • A useful index into the patterns is found inside the front cover • Not only what pages they’re on, but brief snippets summarizing intent • Pattern map inside back cover is also helpful • Remembering the relationships between patterns (add your own arcs) • PH chapter 2 gives a nice sequence of “teaching examples” • Patterns are motivated and applied in a fairly controlled way • Straightforward progression for introducing others to how patterns work • Useful as a guide to basic principles of pattern-oriented design • PH chapter 3 is a bit messier, more like “real-world” examples • E.g., “Left-over” design forces from Type Laundering example • Need to avoid leaking dynamically created cursors • Cannot predict when clients will obtain/release them • Solutions may involve design idioms (narrower applicability) and design heuristics (somewhat less codified/standard) as well as other patterns • E.g., handle-body, reference counting idioms

10. Pattern Authorship is Worth Studying Too • PH chapter 1 gives a nice justification for what pattern-oriented design is (and is not) and for why to invest in learning to do it (and possibly to teach it and/or contribute to its literature) • PH chapter 4 is a look inside the process of authoring patterns • Sometimes a bit like learning how law or sausage is made ;-) • The style of argument and the questions raised are very useful, though • Especially to build your judgment and intuition in applying patterns • PH chapter 5 offers concise advice for pattern authors/users • Hard won lessons from the kinds of experiences in PH chapter 4 • Also applicable to developing/justifying designs as well as patterns • Also applicable to other forms of writing and communication

11. Concluding Remarks • Design is an essential development stage • After requirements, but before implementation • Worth splitting into high and low level stages • Worth detailed discussion, justification, iteration • Studying (and writing) patterns is beneficial • Gives designers a higher level vocabulary • “Both Façade and Interpreter can decouple subsystems” • Can be incorporated into many methodologies • We’ve done a combination of XP and spiral development • Supports justified reuse of design information • Among designers/developers of all levels of expertise

12. Thanks Mastery is a path, not a destination • George Leonard “…if you only walk long enough.” • Lewis Carroll I have learned a lot from our discussions, and I hope you have gained as much from them as well. Last but not least, after you have turned in your final exam and individual 360 review forms, please fill out your on-line course evaluations: http://evals.wustl.edu