CSE 332: Design Patterns (Part I) Introduction to Design Patterns Design patterns were mentioned several times so far –And the Singleton Pattern was discussed in detail –Along with several C++ memory management idioms The lectures this week will focus on them in detail –What they are and how they are structured –Introduction to the main “Gang of Four” design patterns The first set of design patterns should feel familiar –They use or help support C++ features we’ve discussed –We’ve seen examples of some of them already The second set is useful for advanced design topics –Different ways to set up how a group of objects interacts –How to send an object from one machine to another

CSE 332: Design Patterns (Part I) 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 332: Design Patterns (Part I) “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 –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 332: Design Patterns (Part I) 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 (static 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 332: Design Patterns (Part I) 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 332: Design Patterns (Part I) 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 332: Design Patterns (Part I) 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 332: Design Patterns (Part I) 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 332: Design Patterns (Part I) Part I: Familiar Design Patterns First, a few more patterns related to course so far –Iterator: access elements sequentially no matter how stored –Adapter: converts interface you get into one you want –Factory method: creates a related type polymorphically Next lecture we’ll examine other important patterns –Bridge: allow interface, implementation to vary separately –Chain of responsibility: give request to chain of handlers –Composite: common interface to composite/simple objects –Interpreter: build a representation for a simple language –Observer: tell registered observers when state changes –Strategy/template method: vary steps/all of an algorithm –Proxy: forward requests from placeholder to another object –Memento: package up object state without violating encapsulation –Visitor: allow various operations on fixed set of objects (2-way dispatch)

CSE 332: Design Patterns (Part I) Iterator Pattern Problem –Want to access aggregated elements sequentially E.g., traverse a list of names and print them out –Don’t want to know details of how they’re stored E.g., in a linked list, or an array, or a balanced binary tree Solution core –Provide a separate interface for iteration over each container Consequences –Frees user from knowing details of how elements are stored –Decouples containers from algorithms (crucial in C++ STL) Examples we’ve seen before –C++ pointers, C++ STL list ::iterator

CSE 332: Design Patterns (Part I) Iterator Pattern Structure Diagram > first() next() is_done() current_item() > create_iterator() creates has-a Each container may have a different iterator type Iterator knows the internals of the container Object-oriented form shown below (for user-defined types) Slightly different with built-in types, templates –E.g., no inheritance relationship, may use traits, etc.

CSE 332: Design Patterns (Part I) Object-Oriented Iterator Example class StringIterator { public: StringIterator (char * s) : s_ (s), current_ (s) {} void first () { current_ = s_; } void next () { ++current_; } bool is_done () { return *current_ == 0; } char * current_item () { return current_; } private: char *s_; char *current_; }; Object-oriented version of iterator is natural to implement as a class in C++ Constructor stores passed pointer to C- style string s, positions current_ at s first (re)positions iterator at the start of the string next moves iterator to the next position is_done tests whether iterator is at the end of the string current_item returns a pointer to the character at the current iterator position

CSE 332: Design Patterns (Part I) Using an Object-Oriented Iterator unsigned int letter_count (StringIterator & si, char c) { unsigned int count = 0; for (si.first (); ! si.is_done ( ); si.next ()) if (*si.current_item () == c) ++count; return count; } Iterators naturally support use in looping constructs Here we show a for loop –first is used to initialize –is_done used for loop test –next used to increment –current_item is used in loop body’s value comparison When the loop completes, the function shown has –Iterated through entire string –Counted occurrences of the character value in the string –Returned the occurrence count

CSE 332: Design Patterns (Part I) Using a Procedural Iterator. unsigned int letter_count (char * si, char * start, char c) { unsigned int count = 0; for (si = start; *si != 0; ++si) if (*si == c) ++count; return count; } This pattern is not limited to C++ or even to object-oriented languages –For example, C code to the left Some changes are needed –Need to pass in start of string (not encapsulated in iterator class) –Syntax for pointer operators instead of method invocations Solution core clearly the same –Program pretty much the same –Result of function is the same –Looks a lot like STL examples

CSE 332: Design Patterns (Part I) Adapter Pattern Problem –Have an object with an interface that’s close to but not exactly what we need Context –Want to re-use an existing class –Can’t change its interface –Impractical to extend class hierarchy more generally Solution –Wrap a particular class or object with the interface needed (2 forms: class form and object forms) Consequences –Implementation you’re given gets interface you want

CSE 332: Design Patterns (Part I) Adapter Pattern Structure Diagram (Class Form) Abstract base class provides desired interface Concrete Impl class provides the implementation Adapter glues them together via inheritance InterfaceImpl method () = 0;impl_method (); Adapter method (); public private

CSE 332: Design Patterns (Part I) Adapter Pattern Structure Diagram (Object Form) Abstract base class provides desired interface Concrete Impl class provides the implementation Adapter class glues them together via delegation Interface Impl method () = 0; impl_method (); Adapter method ();

CSE 332: Design Patterns (Part I) Factory Method Pattern Problem –You want a class to create a related class polymorphically Context –Each class knows which version of the related class it should create Solution –Declare abstract method that derived classes override Consequences –Type created matches type(s) it’s used with Container Iterator * make_iterator()=0; Array Iterator * make_iterator(); Linked_List Iterator * make_iterator(); Iterator first()=0; next()=0; current()=0; is_done()=0; Array_Iterator first(); next(); current(); is_done(); List_Iterator first();next(); current(); is_done();

CSE 332: Design Patterns (Part I) Object-Oriented vs. Generic Variations Use Factory Method pattern if you have inheritance hierarchies of classes (with abstract base classes) Use the Traits idiom when you want a generic programming version of this technique –E.g., when you have unrelated classes capable of providing common interfaces (like STL vectors and linked lists) Traits version relies on templates and compile-time dispatching of calls Inheritance based version relies on run-time dynamic resolution of calls (virtual functions and overriding)

CSE 332: Design Patterns (Part I) Summary We’ve looked at a number of important patterns so far –Singleton: share a class instance across multiple uses –Command: package up a function as an object –Iterator: access elements sequentially no matter how stored –Adapter: converts interface you get into one you want –Factory method: creates a related type polymorphically Next time: Design Patterns II –Bridge: allow interface, implementation to vary separately –Chain of responsibility: give request to chain of handlers –Composite: common interface to composite/simple objects –Interpreter: build a representation for a simple language –Observer: tell registered observers when state changes –Strategy/template method: vary steps/all of an algorithm –Proxy: forward requests from placeholder to another object –Memento: package up object state without violating encapsulation –Visitor: allow various operations on fixed set of objects (2-way dispatch)