What’s a Pattern? What’s an Idiom?

1. 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

2. “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

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., 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. 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

5. Structure Diagram Example: “Command” • Shows fixed class/interface rolesin the pattern • Shows fixed relationships between roles <<Client>> client role command role * <<Command>> <<Invoker>> execute ( ) inheritance <<ConcreteCommand>> <<Receiver>> execute ( ) action(args) state_

6. 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 aClient aReceiver aCommand anInvoker construct store time / / / / / / / / action execute

7. 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

8. 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)