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 Books 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 isnt
• 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 Books Forward

• The GoF books 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 Books Guide to Readers

• Multiple ways to read this book (well 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 Books 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 recurring problem
• 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 Boochs 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 genres
  attributes

9
A Catalog of Design Patterns (GoF 1.4, 3, 4, 5)

• Each patterns name and intent are listed
• Along with the page number in the GoF book where
  it starts
• List is also inside the books front cover for
  quick access
• Patterns are listed alphabetically by name in 1.4
  
• In the catalog theyre 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)

• (Well 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 youve 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 whats 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, whats 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 isnt 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 dont the GoF design patterns
  address?