So when someone says “adapter” you know what they mean

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 behav

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

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

Structural Patterns

• Help define fixed structural relationships

– Between classes, and their associations

• Emphasis on the class diagrams

• Example

– Adapter pattern

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

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)

Adapter Structure (Class Form)

• Interface abstract base class provides desired interface

• Impl concrete class provides the implementation

• Adapter glues them together via inheritance

Interface Impl method () = 0; impl_method ();

Adapter

method () { impl_method ();

};

public private

Adapter Structure (Object Form)

• Interface abstract base class provides desired interface

• Impl concrete class provides the implementation

• Adapter glues them together via delegation

Interface

Impl method () = 0;

impl_method ();

Adapter

method () {

impl_->impl_method();

};

impl_

Behavioral Patterns

• Help define dynamic behavioral relationships

– Between objects at run-time

• Emphasis is on interactions among objects

• Examples

– Memento pattern

– Observer pattern

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

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

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

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

Observer Pattern Behavior

<<Subject>>

register()

notify()

∆ state

register()

update()

update()

(optional)