DESIGN PATTERNSDon’t reinvent the wheel

The Design Patterns Book

Design Patterns

“simple and elegant solutions to specific problems in object-oriented software design” If there are “tried and true” approaches

that have worked on similar problems in the past, you can benefit by adopting them.

Design patterns can enhance the vocabulary of design The people you are talking to have to

know the names and meanings of the patterns

Patterns are Reusable Solutions Each pattern has

A pattern name Naming the pattern provides powerful

short-hand for design solutions A problem description

The problem in general terms A solution

Describes the design A set of consequences

Trade-offs involved in applying the pattern

Inheritance versus Composition

Object Inheritance (is a) Whitebox reuse

Internals of parent class often visible Breaks encapsulation

Can’t change at runtime Non-abstract base classes define part of physical

representation Directly supported by language (polymorphism) Easy to modify an existing implementation

Object Composition (has a) Blackbox reuse

Internals of delegate class not visible Can change at runtime (limited by base class data type) Fewer implementation dependencies Smaller hierarchies

Prefer Composition to Inheritance

Delegation A object contains a delegate object

Requests to the object are explicitly referred to the delegate, similarly to how a subclass implicitly refers functions that have not been overridden to its parent class.

Disadvantage Dynamic, parameterized software is

harder to understand

Singleton Intent:

Ensure a class only has one instance, and provide a global point of access to it.

Motivation It’s important for some classes to have exactly

one instance. We often need global access to just objects

Applicability Exactly one instance of a class must be

accessible to clients from a well-known access point

The sole instance should be extensible by subclassing

Implementation in C++

Static Singleton* Instance(); Instance does one of the following

Creates an instance of the class and returns it, storing the value as a static private data member

Returns a previously created instance

Protected Singleton constructor External code cannot create an instance

of the singleton class

Singleton Example

SpriteLand Design Patterns uses Instance()

We use getSpriteLand() Look at SpriteLand implementation

Multithreading Considerations for Singleton from “Head First Design Patterns”

Need some synchronization to prevent the creation of multiple instances Use “synchronized” keyword for Java

constructor private static synchronized Singleton getInstance()

Create the single instance before any calls to the singleton class private static Singleton instance_ = new Singleton();

Use “double-checked locking” If (instance_ == null)

Synchronized (Singleton.class) { if (instance_ == null) {

uniqueInstance = new Singleton();

Consider needs for mutual exclusion in other singleton methods. Remember, access to data member

in the singleton are shared and might require synchronization.

Creational Patterns

Factory Abstract Factory Builder Prototype Singleton

Factory Method (Virtual Constructor) Define an interface for creating an object, but let subclasses

decide which class to instantiate. class TowerDefenseGame { // Factory methods virtual Path* makePath(); virtual Tower* makeMonkeyTower(); } // The TowerDefenseGame can be subclassed to

//EasyTowerDefenseGame and DifficultTowerDefenseGame

makePath() and makeMonkeyTower() are overridden so that EasyTowerDefenseGame::makePath() returns an instance of class EasyPath, and DifficultTowerDefenseGame::makePath() return an instance of class DifficultPath.

Abstract Factory (or Kit)(Factory that uses delegation rather than inheritance) Provide an interface for creating families of related or

dependent objects without specifying their concrete classes. class ComponentFactory { Path* makePath() = 0; Tower* makeMonkeyTower() = 0; }; class TowerDefense { public: Path* makePath() { componentFactory-

>makePath(); } private:

ComponentFactory* componentFactory_;

};

Prototype Specify the kinds of objects to create using a prototypical

instance, and create new objects by copying the prototype. class TowerDefenseGame { public: TowerDefenseGame(Path* prototypePath, Tower* prototypeMonkeyTower) :

prototypePath_(prototypePath), prototypeTower_(prototypeTower) {}

Path* makePath() { return prototypePath_.clone(); } Tower* makeMonkeyTower() { return prototypeTower_.clone(); }

private: Path* prototypePath_; Tower* prototypeTower_; }

Structural Design Patterns How classes and objects are

composed to form larger structures Structural class patterns use inheritance

Structural object patterns use composition

Adapter (aka Wrapper)

Convert the interface of a class into another interface clients expect. Can use multiple inheritance

Structural class pattern Can use composition

Structural object pattern

Bridge (aka Handle/Body aka PIMPL) Decouple an abstraction from its

implementation so that the two can vary independently.

C++ Pointer to implementation class myClass { public: // Define public interface

private: myClassImpl* implementation;

};

Uses for Bridge

Completely divorce public interface from implementation. (C++ headers)

Allow different implementations to be assigned at runtime.

You want to share an implementation between multiple objects

Some Sample Patterns (from the Design Patterns Book)

Singleton Ensure a class only has one instance, and provide a

global point of access to it. Factory Method

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

Bridge Decouple an abstraction from its implementation so that

the two can vary independently Façade

Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use.

Composite

Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. Problem – We want to build composite objects from

primitive objects, and then use the composites as though they are primitives.

Abstract base class represents both primitives and their containers.

Windows Forms use this pattern. Windows have components that can also be windows Messages sent to windows are forwarded to their

components.

Decorator

Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. Decorators are implemented as classes that

contain an instance (component) of the thing that they are decorating Example

Window contained in a ScrollingDecorator which in turn is contained in a BorderDecorator. Window requests are routed first to the outer-most decorator and forward to inner decorators until finally reaching the window.

Decorator Implementation

Decorator must conform to interface of decorated component.

Decorators should be light-weight (focus on interface, not data storage).

Change the skin of an object rather than change the guts.

Facade

Provide a unified interface to a set of interfaces in a subsystem Provide a single-point of contact

between subsystems Provide a task-oriented interface to a set

of components (compile, rather than scan, parse, generate code, optimize, etc).

Decouple dependencies between components and component clients.

Flyweight

Use sharing to support large numbers of fine-grained objects efficiently Flyweight is a shared object that can be used in

multiple contexts simultaneously Intrinsic state

What is stored inside the flyweight Independent of flyweight’s context

Extrinsic state Client objects track the extrinsic state and pass it to

member functions that need it. Example

Flyweight for each letter in a text document Position and typographic style are extrinsic state

Flyweight Applicability

Application uses a large number of objects

Most object state can be extrinsic Many instances can make use of a

shared object.

Proxy

Provide a surrogate or placeholder for another object to control access to it.

Uses An expensive class can be replaced by a

proxy until it must be created Control access based on a set of access

rights Smart pointers!

Behavioral Patterns

Behavioral class patterns Use inheritance

Behavioral object patterns Use composition

Chain of Responsibility

Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. Each object, starting with the first in in a

chain of objects, get a chance to handle the request, or pass it along the chain. Example

Windows

Command

Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue, or log requests, and support undoable operations. Use when you want to build an object

that invokes a command (like a UI button), and you don’t want to tie a button press to a hard-coded function.

Delegates in C# come to mind Execute() can store state to provide an

Unexecute() function.

Iterator (aka Curso)

Provide a way to access the elements of an aggregate (collection) object sequentially without exposing its underlying representation. Support variation in traversal method

Preorder, postorder, inorder tree traversal Simplify the interface Use of multiple iterators allows us to

keep track of multiple places in the aggregate.

Mediator

Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.

Each object knows only of the Mediator Reduce coupling between components

Mediator must know objects and interactions

Centralizes control Simplifies object protocols

Memento (aka Token)

Without violating encapsulation, capture and externalize an object’s internal state. Often used to restore state via undo

operations Originator (the class whose state will be

saved as a memento) supports the methods CreateMemento() // Create a memento

with state SetMemento(Memento m) // Restore

state Mementos are opaque objects that are

used only for setMemento operations

Observer (aka publish-subscribe) Define a one-to-many dependency between

objects so that when one object changes state, all its dependents are notified and updated automatically. Example:

Spreadsheet data used to generate a grid-view of the data and several different types of data When the underlying data changes, all presentations must

be updated. The “Subject” knows its observers

Subject notifies each observer of change Upon notification, observers request data from subject

In Model/View/Controller pattern, model is subject, views are observers.

State

Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.

Abstract “State” class contains a pointer to concrete state classes that to whom all requests are delegated. Example:

Person class might be implemented as an abstract state where Sleeping Working Playing

provide concrete implementations of “answerPhone()”