“Design Patterns”

1. “Design Patterns” • A popular and influential software engineering text • Published in 1995 amid upsurge of OO programming • Triggered widespread and ongoing interest in patterns • Often referred to as the “Gang of Four” (GoF) book • Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides • Thanks to Stephen Jewett (CSE 432 Spring 2006) for the following ha-ha-only-serious observation: “Warning – Reading this Book May Cause an Uncontrollable Urge to Redesign Everything”

2. GoF Book’s Preface • Assumptions about readers’ background • Familiarity with object-oriented design ideas • E.g., polymorphism, types, interface, implementation, etc. • A willingness to revisit (see iterator pattern :-) the ideas • What this book isn’t • A deeply technical or formal treatment of programming • I.e., other texts cover type theory, automata, algorithms, etc. • A recipe (or cookbook) for generating a design or designs • What this book is • A (potentially new) way of thinking about program design • A great source of small illustrative design examples • A resource to return to again and again as you design code

3. GoF Book’s Forward • The GoF book’s forward was written by Grady Booch • An early leader in the development of object-oriented design • Founded Rational Software, which IBM later acquired • The Booch Method was merged with OMT to form UML • An important observation about software and patterns • Well structured object-oriented software is “pattern-rich” • “Collaborations” among objects are common (recurring) • This level of detail is crucial to crafting complex systems well • Connecting building and software architecture • Alexander et al. used patterns to characterize houses, cities • Gamma, Helm, Johnson, Vlissides showed how that idea can be translated to software systems

4. GoF Book’s Guide to Readers • Multiple ways to read this book (we’ll use all 3 ways) • As a textbook: a primer, then a case study, then a catalog • As a design treatise: from common problems to specifics • On-demand: skipping around based on what you need • Suggestions for simple and common patterns to study • Abstract Factory • Adapter • Composite • Decorator • Factory Method • Observer • Strategy • Template Method

5. GoF Book’s Introduction • Designing reusable object-oriented software is difficult • Objects, classes, interfaces, hierarchies, associations • Structure how these different features inter-relate in a design • Expert designers already know how to do this well • They also re-use solutions (or parts of solutions) that work • How can what they re-use be captured, and communicated? • Key idea is that the problems and their solutions recur • So we can document problems and solutions together • Design patterns do this recording, in an accessible form • Helps us remember patterns, and learn new ones

6. What is a Design Pattern? (GoF 1.1) • A pattern has a name • So that we can refer to it, as part of a design vocabulary • A pattern documents a recurringproblem • Tells us when to apply the pattern, and in what contexts • A pattern describes the core of a solution • An approach that we can apply/adapt in different contexts • Not a recipe for a concrete design (not so narrow/limited) • A pattern documents resulting consequences • Possible trade-offs in applying that solution to that problem • New problems that may arise due to the use of the pattern

7. Model-View-Controller Case Study (GoF 1.2) • A nice illustration of Grady Booch’s observation • Well-structured software (MVC vs. monolithic interfaces) • Evident patterns (Observer, Composite, Strategy, etc.) • Observation holds true even for many small examples • Thought question: is MVC itself a pattern? • Are a name, problem, solution, and consequences evident? • How general is its domain of applicability? • Can it be decomposed further into more fundamental patterns?

8. Describing Design Patterns (GoF 1.3) • We said what features a pattern must have • a name, problem, solution, and consequences (inherent) • But, what else is useful to describe about a pattern? • GoF authors present one such layout in the book • “Intent” is particularly useful (see 1.4, inside front cover) • “Also known as” helps prune proliferation of names (a key merit of patterns lies in commonality rather than originality) • Structure/collaborations relate to design methodology (UML) • Sample code illustrates use of the pattern concretely • Known uses help document recurrence of the pattern • There are many other formats in the patterns literature • GoF format is merely one of the more popular ones • Each establishes a particular genre for describing patterns • And, some authors use some or all of a genre’s attributes

9. A Catalog of Design Patterns (GoF 1.4, 3, 4, 5) • Each pattern’s name and intent are listed • Along with the page number in the GoF book where it starts • List is also inside the book’s front cover for quick access • Patterns are listed alphabetically by name in 1.4 • In the catalog they’re organized by category of purpose • I.e., creational, structural, or behavioral (Table 1.1 in 1.5)

10. Catalog Organization (GoF 1.5) • GoF patterns are creational, structural, or behavioral • Creational patterns involve construction of new objects • Structural patterns involve static class/object relationships • Behavioral patterns involve dynamic (run-time) interactions • Apply (primarily) to classes, objects, or both • E.g., class form of adapter involves (private) inheritance • E.g., object form of adapter involves delegation

11. How to Select a Design Pattern (GoF 1.7) • (We’ll come back to GoF section 1.6 in a moment) • Think concretely about your design problem (GoF 1.6) • Object/interface/implementation level structure matters • Everything you’ve already learned about design still applies • Look at the intent descriptions in 1.4 (as a quick index) • Think about how patterns interrelate in evolving design • See patterns map on page 12 in 1.6, and inside back cover • Would other patterns in the same category fit better? • Creational, structural, or behavioral • Watch and avoid causes of redesign (page 24 in 1.6) • Consider what should be fixed and what should vary • See table 1.2 on page 30

12. How to Use a Design Pattern (GoF 1.8) • First, skim a pattern to determine whether its useful • Look especially at applicability and consequences • If it looks like a good match, study it more thoroughly • Understand classes, static and dynamic structure • Look at the code examples for implementation ideas • Start with high level design • Initially, name the participants in your design (descriptively, aptly, and clearly) • Make sure the participants fulfill pattern roles well • Move into low level design (specification of classes) • Lay out class members, interfaces, associations • Move from there into implementation • Define class methods, their interactions within the system

13. How Patterns Solve Design Problems (GoF 1.6) • First, a few reminders/pointers to useful info • Patterns list inside front cover and on pages 8-9 • Patterns map inside back cover and on page 12 • Diagram notation in Appendix B and inside back cover • Section 1.6 focuses on how design patterns fit within established object-oriented development techniques • Patterns augment rather than replace existing methods • Section 1.6 follows standard design evolution described in section 1.8 • Begin with high-level design (identifying participants) • Move to low-level design (specify concrete relationships) • Move to implementation (define concrete behaviors)

14. Finding Appropriate Objects • This should all be very familiar in OO design • An object combines data and behavior • An object plays a role within a program (does something) • Not all objects are immediately obvious • Try the “noun/verb” trick for spotting objects • A variant of the CRC approach (not part of GoF per se) • In any requirement, try to write as concretely as possible • Should have lots of description of what’s done by whom • Underline nouns in the description as potential objects • Underline verbs in the description as potential behaviors • Identifying object granularity and multiplicity also matters for pattern choice (flyweights vs. singletons)

15. Specifying Object Interfaces • Pay attention to operations and their signatures • Name and ordered list of types supplied to an operation • Collect common sets of operations into cohesive abstractions (possibly organized hierarchically) • Allows polymorphic substitution of objects per subtyping

16. Specifying Object Implementations • Once the interfaces are established, what’s left? • Need to identify necessary data to implement interface operations • Need to establish class relationships allowing substitution of objects passed as operation arguments • E.g., inheritance for object-oriented polymorphism • E.g., models relations for generic (interface) polymorphism • Need to establish other relationships like delegation, etc. based on interfaces rather than on implementations (so design isn’t brittle to changes)

17. Putting Re-use Mechanisms to Work • Inheritance vs. composition • Inheritance of interface vs. implementation • Delegation as a powerful form of composition (allows replacement of target class even at run-time if necessary) • Inheritance vs. parameterized types • This has come a long way since 1995, but they anticipated several of the most important issues at least abstractly

18. Relating Run-Time and Compile-Time Structures • Different languages have different compile time vs. run-time features (say, Smalltalk vs. C++) • Even within a language, these distinctions matter • Run-time polymorphism with C++ virtual member functions • Compile-time polymorphism with C++ templates and traits • Careful attention to when things can change as well as what can change is crucial to robust design

19. Designing for Change • Change can be required at several different scales • Fine-grained time scale (e.g., run-time object substitution) • Medium-grained time scale (e.g., program updates) • Long-term time scale (e.g., system requirement evolution) • Designing for change is crucial to master • Pages 24 through 28 offer tips and ideas • With pointers to specific patterns that are relevant (a very nice guide to go back to again and again as you design) • Experience with when to worry about change also helps • Design with the idea that change is “looking over your shoulder” at all times

20. Summary and Review Questions • The GoF book presents a useful design pattern genre • And a catalog of many important patterns described that way • The GoF book also motivates and describes the process of pattern-oriented design, with examples • E.g., MVC involving observer, strategy, composite, etc. • Thanks to Genevieve Gurney (CSE 432 Spring 2006) for the following review questions: “What are the four essential elements of a design pattern?” “What design issues don’t the GoF design patterns address?”