Course Summary: CSE 432

1. Course Summary: CSE 432 • 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, Mediator vs. Façade) • Using patterns in specific design scenarios • Chapters 2, 3 in the Pattern Hatching text • 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 + iterator + visitor (modify a structure) • Record 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

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, larger 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 • Unsuccessful combinations leave forces unresolved • As a design evolves, forces and 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 • 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. Re-Read Pattern Hatching and GoF 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. Understand Pattern Authorship • 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, please fill out your on-line course evaluations (by May 3rd) if you’ve not done so already: http://evals.wustl.edu