CSE 432: Design Patterns Introduction What’s a Pattern? What’s an Idiom? According to Alexander, a pattern: –Describes a recurring problem –Describes the core of a solution –Is capable of generating many distinct designs An Idiom is more restricted –Still describes a recurring problem –Provides a more specific solution, with fewer variations –Applies only to a narrow context e.g., the C++ language

CSE 432: Design Patterns Introduction “Gang of Four” Pattern Structure Gang of Four (GoF): Gamma, Johnson, Helm, Vlissides –Authors of the popular “Design Patterns” book 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 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

CSE 432: Design Patterns Introduction 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., 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

CSE 432: Design Patterns Introduction A More Complete Pattern Form: “Command” Problem –Want to issue requests to objects –Don’t know in advance which request(s) will be made –Don’t know in advance to what object(s) they will go Solution core –Encapsulate function call parameters and target object reference inside an “execute” method Consequences –Decouples invocation/execution –Commands are first-class objects (elevates functions) –Easy to compose, add new ones Example we’ve seen already –STL function objects

CSE 432: Design Patterns Introduction Structure Diagram Example: “Command” Shows fixed class/interface roles in the pattern Shows fixed relationships between roles > action(args) execute ( ) state_ * client rolecommand role inheritance

CSE 432: Design Patterns Introduction Collaboration Diagram Example: “Command” Shows dynamic interactions between pattern roles –Labels show what interaction does (here, labels show methods called) Often used to diagram each of several key scenarios –“Happy path” when everything works, plus different error cases aCommandanInvokeraClientaReceiver / construct store executeaction time

CSE 432: Design Patterns Introduction Idiom Example: Guard Problem –Want to tie key scoped behaviors to actual program scopes e.g., program trace, resource acquisition/release, locking –However, tying functions to functions is error-prone e.g., forgetting the release call, exceptional return paths Solution –Design a special adapter class whose constructor and destructor call the key scope entry and exit behaviors –Create a guard object on the program call stack (in a scope) Context limitations –Mainly limited to languages with constructor/destructor

CSE 432: Design Patterns Introduction What is a Pattern Language? A pattern resolved some forces –But may leave others unresolved Applying additional patterns helps resolve them –Repeat until all forces are resolved A well-chosen sequence of patterns –Resolves all design forces adequately –Is some times called “generative” Self-consistent, can produce/generate a good design A pattern language is a narrative –Of the trade-offs in navigating from requirements to design –Chapters in Pattern Hatching give small pattern languages –This is different than a pattern catalog (the GoF book)