Review Design Pattern Structure A design pattern has

Review: Design Pattern Structure • A design pattern has a name – So when someone says “Adapter” you know what they mean – So you can communicate design ideas as a “vocabulary” • A design pattern describes the core of a solution to a recurring design problem – So you don’t have to reinvent known design techniques – So you can benefit from others’ (and your) prior experience • A design pattern is capable of generating many distinct design decisions in different circumstances – So you can apply the pattern repeatedly as appropriate – So you can work through different design problems using it CSE 332: Design Patterns

Three Design Patterns Involving Classes • Adapter (structural) – Converts an interface you have into one you want • Memento (behavioral) – Externalizes the state of an object • Observer (behavioral) – Tells objects about changes in another object CSE 332: Design Patterns

Structural Patterns • Help define fixed structural relationships – Between classes, and their associations • Emphasis on the class diagrams • Example – Adapter pattern CSE 332: Design Patterns

Inconsistent Interfaces • Challenge – Different code bases are often written by different developers, at different times, with different design goals – Interfaces expected by one piece of code are not always the same as those provided by the other code that’s available • Motivates use of the Adapter pattern – Provides a class that exposes the interface that’s needed – That interface is implemented using calls to methods of the existing object(s) – A related pattern called “Wrapper Façade” provides a similar capability by wrapping functions (e. g. , socket calls, etc. ) CSE 332: Design Patterns

Adapter Pattern • Problem – Have an object with an interface that’s close to (but is not exactly) what we need • Context – Want to re-use an existing class – Can’t change its interface – It’s impractical to extend class hierarchy more generally • Solution Core – Wrap a particular class or object with the interface needed (2 forms: class form and object forms) CSE 332: Design Patterns

Adapter Structure (Class Form) Interface Impl method () = 0; impl_method (); private public Adapter method () { impl_method (); }; • Interface abstract base class provides desired interface • Impl concrete class provides the implementation • Adapter glues them together via inheritance CSE 332: Design Patterns

Adapter Structure (Object Form) Interface method () = 0; impl_ Adapter Impl impl_method (); method () { impl_->impl_method(); }; • Interface abstract base class provides desired interface • Impl concrete class provides the implementation • Adapter glues them together via delegation CSE 332: Design Patterns

Behavioral Patterns • Help define dynamic behavioral relationships – Between objects at run-time • Emphasis is on interactions among objects • Examples – Memento pattern – Observer pattern CSE 332: Design Patterns

Adding State Persistence • Challenge – Want to save and restore an object’s state – For example, between different runs of a program • Motivates use of the Memento pattern – – Serialize an object’s state into an opaque “cookie” Format of cookie can be tailored to storage format Can send it to a file, a caretaker object, another computer Can reconstitute object from its memento later/elsewhere CSE 332: Design Patterns

Memento Pattern • Problem – Want to externalize state of an object without violating encapsulation • Context – A snapshot of object state is needed – Providing a state interface would violate encapsulation • Solution Core – Create a memento class with methods to get, set state – Provide an opaque representation of state itself • Consequences – Can use memento to send object state over a socket, save it in a file, put it into a checkpoint/undo stack, etc. CSE 332: Design Patterns

Inter-dependent Object Behaviors • Challenge: need to coordinate object state changes – For example, a sensor may record current temperature – Other objects (e. g. , thermostat) need to know when the temperature changes • Motivates use of the Observer pattern – Helps to keep objects mostly independent – Separates registration, notification, and actions – But, still allows appropriate coordination among objects CSE 332: Design Patterns

Observer Pattern • Problem – Need to update multiple objects when the state of one object changes • Context – Multiple objects depend on the state of one object – Set of dependent objects may change at run-time • Solution core – Allow dependent objects to register with object of interest, notify them of updates when state changes • Consequences – When observed object changes others are notified – Useful for user interface programming, other applications CSE 332: Design Patterns

Observer Pattern Behavior <<Subject>> <<Observer>> register() (optional) ∆ state notify() update() CSE 332: Design Patterns