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 whats 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 its never used
• Object is shared efficiently among all uses

4
Pattern-Oriented Software Design Development

• Weve 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 dont 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)

UndoCommand
UndoStack
Client
System
action
remember
construct
store
time
/ /
/ /
/ /
/ /
undo
execute
restore
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 dont have a closed form inverse
• Memento can remember state prior to command use
• Strategy supports both kinds of Command inverses

UndoCommand
UndoStack
Client
System
action
remember
construct
store
time
/ /
/ /
/ /
/ /
undo
execute
restore
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 theyre 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
• Weve 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 youve not
  done so already
• http//evals.wustl.edu