2.

4 Memento Pattern

2.4.1 Identification
Name Classification Strategy
Memento Behavioural Delegation (Object)
Intent
“Without violating encapsulation, capture and externalise an object’s internal state
so that the object can be restored to this state later.” ([2]:283)
2.4.2 Structure

Figure 10: The structure of the Memento Pattern

2.4.3 Problem
The memento pattern enables an object to be restored to its previous state. Memento can
be seen as a snapshot of the system at a particular point in time.

1
2.4.4 Participants
Originator

• an object with an internal state which it creates a snapshot of to store

• the snapshot is used to restore the state

Memento

• takes a snapshot of as much state as required by the originator

• only allows the originator access to the state

Caretaker

• keeps the memento safe

• is unaware of the structure of the memento

The two main participants on the pattern are the Originator and the Caretaker. A wide interface exists between the Originator and the
Memento, while a narrow interface exists between the Caretaker and the Memento.

2.5.3 Related Patterns

Command
Command can make use of mementos to maintain the state of commands, in the order they were issued, in order to support
undoable operations.

Iterator
Mementos can be used for iteration to maintain the state of the iterator.

Bridge
The bridge pattern can be applied in order to separate the interface from the implementation of the memento in order to
provide the wide interface between the originator and the memento without using the friend technique which violates
objectoriented encapsulation.

2
.3 Template Method Pattern

3.3.1 Identification
Name Classification Strategy
Template Method Behavioural Inheritance
Intent
Define the skeleton of an algorithm in an operation, deferring some steps to
subclasses. Template Method lets subclasses redefine certain steps of an algorithm
without changing the algorithm’s structure. ([2]:325)
3.3.2 Structure
The structure of the Template Method design pattern is given in Figure 2. The design
pattern comprises of two classes, the abstract class which defines the interface and the
template method function. This function defers implementation of primitive operations
to its subclass.

3.3.3 Problem
Two different components have significant similarities, but demonstrate no reuse of
common interface or implementation. If a change common to both components becomes
necessary, duplicate effort must be expended [3].

Figure 2: The structure of the Template Method pattern

Figure 3: The Hollywood principle

1
3.3.4 Participants
AbstractClass

• Implements a template method defining the skeleton of an algorithm. Among

others, this method calls a number of defined primitive operations.
• Defines abstract primitive operations that appear as steps in the template
method.

ConcreteClass

• Implements the defined primitive operations to carry out the subclass-specific

steps of the algorithm.

3.4.5 Related Patterns

Strategy
Both Strategy and the Template Method pattern defer implementation. However, Strategy
uses delegation to defer the implementation of a complete algorithm while the Template
Method pattern uses inheritance to defer only specific parts of an algorithm.

Factory Method
Although the Factory Method is not a specialisation of the Template Method pattern,
it is related to the Template Method pattern. Many of the non-virtual methods that
participate as AnOperation() in solutions that apply the Factory Method pattern are
often template methods that, among others, call factory methods.

Adapter
Both the Adapter pattern and the Template Method pattern provides an interface
through which operations that are implemented in other classes are called. The
difference is that Adapter provides an interface to access non-complying operations
that cannot be changed while the operations accessed through the template method
is expected to comply and are most likely to change.

Builder
Both Builder and the Template Method pattern require a process to be encapsulated
in a method. In fact the method that has to be implemented by the concrete builders
to assemble a product is a template method.

2
4.3 Factory Method Pattern

4.3.1 Identification
Name Classification Strategy
Factory Method Creational Inheritance (Class)
Intent
Define an interface for creating an object, but let subclasses decide which class to
instantiate. Factory Method lets a class defer instantiation to subclasses. ([2]:107)
4.3.2 Structure

Figure 2: The structure of the Factory Method Pattern

4.3.4 Participants
Creator
• declares the factory method which returns a product object
• default factory method implementations may return a default concrete product

ConcreteCreator

• overrides the factory method to return an instance of the product

Product

• defines the product interface for the factory method to create

ConcreteProduct

• implements the interface for the product

1
 Figure 3: UML class diagram of ComplexNumber

4.4.5 Related Patterns

Template Method
The Factory Method may make use of Template Method in both the Product and the
Creator hierarchies.

Abstract Factory
The Factory Method may be used in the implementation of the Abstract Factory
design pattern.

Prototype
Factory Methods can be used to initialise prototypical objects. The prototype also
can be used instead of the factory method to avoid large parallel hierarchies.

Singleton
In only one instance of a concrete factory is required, the concrete factory can be
made a Singleton.

2
5.3 Prototype Pattern

5.3.1 Identification
Name Classification Strategy
Prototype Creational Delegation
Intent
Specify the kinds of objects to create using a prototypical instance, and create new
objects by copying this prototype (Gamma et al. [2]:117)
5.3.2 Structure

Figure 3: The structure of the Prototype Pattern

5.3.3 Problem
The constructor of a class contains computationally expensive or manually time
consuming procedures. These can be avoided by creating a copy of the object rather than
going through the entire creation process each time from the beginning.

5.3.4 Participants
Prototype

• Declares an interface for cloning itself.

ConcretePrototype

• Implements an operation for cloning itself.

Client

1
 • Creates a new object by asking a prototype to clone itself

5.3.5 Alternate Structure

Figure 4: The structure of the Prototype Pattern with a manager

5.3.6 Participants of the alternate structure

Prototype

• Declares an interface for cloning itself.

ConcretePrototype

• Implements an operation for cloning itself.

PrototypeManager

• Is responsible for keeping prototypes and provide functionality to add and

remove prototypes.
• Act as mediator through which the client can ask a selected prototype to clone
itself

Client

• Creates a new object by asking the prototype manager to ask a selected

prototype to clone itself

There are many practical scenarios where this design pattern really helps. Here follows
few of them mentioned by Gibson [3]

2
Factory Method
Both Prototype and Factory Method are creational patterns. However, Prototype use
delegation to create while Factory Method uses inheritance. They can also be used
together. One can design a factory method that accept arguments and uses these
arguments to find the correct prototype object, calls clone() on that object, and
returns the result. The client replaces all references to the new operator with calls
to the factory method.

Abstract Factory
Prototype and Abstract Factory are competing patterns in some ways. Prototype
define new types simply by creating new prototypes while Abstract Factory requires
the creation of new classes for defining new types. However, they can also be used
together. An Abstract Factory might store a set of prototypes from which to clone
and return product objects.
Abstract Factory and Builder
Similar to the prototype design pattern, these patterns hides the concrete product
classes from the client, thereby reducing the number of names clients know about.
Composite and Decorator
Designs that make heavy use of the Composite and Decorator patterns often can
benefit from Prototype.

Singleton and Abstract Factory Prototype, Singleton and Abstract Factory are all
creational patterns where you don’t use the new keyword to create a product but
you call a method that will create the specific product and return a pointer to it.
Singleton, Memento and Flyweight
These patterns administrate access to specific object instances similar to how
Prototype administrates it. All of them offer factory methods to clients and share a
create-on-demand strategy [4].

3
7.2 Abstract Factory Pattern

7.2.1 Identification
Name Classification Strategy
Abstract Factory Creational Delegation (Object)
Intent
Provide an interface for creating families of related or dependent objects without
specifying the concrete classes. (Gamma et al. [1]:87)
7.2.2 Structure

Figure 1: The structure of the Abstract Factory Pattern

7.2.3 Participants
AbstractFactory
• provides an interface to produce abstract product objects

ConcreteFactory

• implements the abstract operations to produce concrete product objects

AbstractProduct

1
 • provides an interface for product objects

ConcreteProduct

• implements the abstract operations that produce product objects that are
created by the corresponding ConcreteFactory

Client

• uses the interfaces defined by AbstractFactory and AbstractProduct

7.3.3 Related Patterns

Factory Method or Protoype
The Abstract Factory makes use of the Factory Method or the Prototype for the
creation of product. The choice of which route to follow is implementation
dependent.

Template Method
May be used within the abstract factory and product hierarchies.

Singleton
Concrete factories may be implemented as Singletons..

2
8.3 Strategy Design Pattern

8.3.1 Identification
Name Classification Strategy
Strategy Behavioural Delegation
Intent
Define a family of algorithms, encapsulate each one, and make them
interchangeable. Strategy lets the algorithm vary independently from clients that
use it
([4]:315)
8.3.2 Structure

Figure 3: The structure of the Strategy Design Pattern

8.3.3 Problem
An implementation implementing different algorithms to solve the same problem requires
uncontrolled coupling with its clients that can be avoided. That is, the implementation
consists of a variation of classes for implementing different algorithms to solve a given
problem and clients need to couple individually with these classes.

8.3.4 Participants
Strategy

• Declares an interface common to all supported algorithms.

• Context uses this interface to call the algorithm defined by a ConcreteStrategy.

ConcreteStrategy

• Implements the algorithm defined by the Strategy interface.

1
Context

• Is configured with a ConcreteStrategy object.

• Maintains a reference to a Strategy object.
• May define an interface that lets Strategy access its data.

2
9.3 State Design Pattern

9.3.1 Identification
Name Classification Strategy
State Behavioural Delegation
Intent
Allow an object to alter its behaviour when its internal state changes.The object will
appear to change its class. ([1]:305)
9.3.2 Structure

Figure 1: The structure of the State Design Pattern

9.3.3 Problem
The two major problem areas [2] that exist in which the state pattern can make a
contribution are:

• when an object becomes large; and

• when there is an extensive number of state changes an object can go through.

The behaviour an object exhibits is dependent on the state of the object. Changing the state
of an object will therefore influence the behaviour of the object at run-time. When objects
become large, changing their state can become difficult. In order to control the complexity
of changing state, the state of the object is managed externally to the object itself.
An object may be required to change state many times and into many different states.
When these states become numerous and the flow is controlled by choice-statements
(such as if or switch in C++), the ability to manage the statement flow diminishes. In order
to control this complexity, the state of an object can be managed externally to the object
itself by modelling the states as objects in their own right.

1
9.3.4 Participants
State

• Defines an interface for encapsulating the behaviour associated with a

particular state of the Context.

ConcreteState

• Implements a behaviour associated with a state of the Context.

Context
• Maintains an instance of a ConcreteState subclass that defines the current state.
• Defines the interface of interest to clients.

9.4.4 Related Patterns

Strategy
The Strategy and State patterns have the same structure and both apply the PV
Principle to achieve their goals. However, they differ in intent. The Strategy pattern
is about having different implementations that accomplishes the same result, so that
one implementation can replace the other as the Strategy requires while the State
pattern is about doing different things based on the state, while relieving the caller
from the burden to accommodate every possible state.

Singleton or Prototype
When implementing the state pattern, the programmer has to decide on how the
state objects will be created. Often the application of the Prototype pattern will be
ideal. State objects are also often Singletons.

Flyweight
State objects can be shared by applying Flyweight.

2
11.3 Composite Design Pattern
11.3.1 Identification
Name Classification Strategy
Composite Structural Delegation (Object)
Intent
Compose objects into tree structures to represent part-whole hierarchies. Composite
lets clients treat individual objects and compositions of objects uniformly. ([2]:163)

11.3.2 Structure

Figure 1: The structure of the Composite Pattern

11.3.3 Problem
Used in hierarchies where some objects are composite of other. Makes use of a store for
the children defined by Composite

11.3.4 Participants
Component

• provides the interface with which the client interacts.

Leaf

• do not have children, define the primitive objects of the composition.

Composite

• contains children that are either composites or leaves.

Client

1
 • manipulates the objects that comprise the composite.
11.4 Composite Pattern Explained
The composite pattern inherently builds a tree (refer to Figure 2) with the intermediate
nodes being instances of composite and the leaf nodes being instances of the leaf
participants.

Figure 2: Examples of tree structures

11.4.2 Related Patterns

Chain of Responsibility
Creates a structure that defines a component-parent link.

Decorator
Used in conjunction with components to add state to the components. When a
decorator and a composite are combined, they usually share the same parent class.

Flyweight
Allows sharing of objects, particularly the leaf nodes

Iterator and Visitor

Used to traverse the composite structure.

2
12.2 Decorator Pattern
12.2.1 Identification
Name Classification Strategy
Decorator Structural Delegation (Object)
Intent
Attach additional responsibilities to an object dynamically. Decorators provide a
flexible alternative to subclassing for extending functionality. ([1]:175)
12.2.2 Structure

Figure 1: The structure of the Decorator Pattern

12.2.3 Participants
Component

• interface for objects that can have responsibilities dynamically added to them

ConcreteComponent

• the object to which the additional responsibilities can be attached

Decorator

• defines a reference to a Component-type object

ConcreteDecoratorA

• adds state-based responsibilities to the component

ConcreteDecoratorB

1
• adds behavioural-based responsibilities to the component

2
14.2 Observer Pattern

14.2.1 Identification
Name Classification Strategy
Observer Behavioural Delegation (Object)
Intent
Define a one-to-many dependency between objects so that when one object changes
state, all its dependents are notified and updated automatically. ([1]:293)
14.2.2 Structure

Figure 1: The structure of the Observer Pattern

14.2.3 Problem
The observer design pattern solves the problem of needing to change the code for every
observer that is related to the subject during maintainance when observers are changed,
added or removed from the system. The pattern facilitates the attaching and detaching of
the observers from the subject leaving the subjects code intact.
14.2.4 Participants
Subject

• Provides an interface for observers to attach and detach to the concrete subject.

ConcreteSubject

• Implementation of the subject being observed.

1
 • Implements the functionality to store objects that are observing it and sends
update notifications to these objects.

Observer

• Defines the interface of objects that may observe the subject.

• Provides the means by which the observers are notified regarding change to
the subject.

ConcreteObserver

• Maintains a reference to the subject it observes.

• Updates and stores relevant state information of the subject in order to keep
consistent with the state of the subject.

2
15.2 Iterator Design Pattern

15.2.1 Identification
Name Classification Strategy
Iterator Behavioural Delegation
Intent
Provide a way to access the elements of an aggregate object sequentially without
exposing its underlaying representation ([3]:257)
15.2.2 Problem
A system has wildly different data structures that are often traversed for similar results.
Consequently traversal code is duplicated but with minor differences because each
aggregate has its own way to provide the functionality to access and traverse its objects.
To eliminate such duplication, we need to abstract the traversal of these data structures
so that algorithms can be defined that are capable of interfacing with them transparently
[4].

15.2.3 Structure

Figure 1: The structure of the Iterator Design Pattern

1
15.2.4 Participants
Iterator

• Defines an interface for accessing and traversing elements.

Concrete Iterator

• Implements the Iterator interface

• Keeps track of the current position in the traversal of the aggregate

Aggregate

• Defines an interface for creating an Iterator object

Concrete Aggregate

• Implements the Iterator creation Interface to return an instance of the proper

concrete iterator.

2
Department of Computer Science

17.2 Mediator Design Pattern

17.2.1 Identification
Name Classification Strategy
Mediator Behavioural Delegation
Intent
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. ([1]:273)
17.2.2 Structure

Figure 1: The structure of the Mediator Design Pattern

17.2.3 Participants
Mediator

• defines an interface for communicating with Colleague objects.

ConcreteMediator

• implements cooperative behavior by coordinating Colleague objects.

• knows and maintains its colleagues.
Colleague

• each Colleague class knows its Mediator object.

1
 • each colleague communicates with its mediator whenever it would have
otherwise communicated with another colleague.

17.2.4 Problem
We want to design reusable components, but dependencies between the potentially
reusable pieces demonstrates the spaghetti code phenomenon. When one wants to reuse
only one or a few of the classes in a group of classes, it is virtually impossible to isolate
them because they are to interconnected with one another. Trying to scoop a single serving
results in an all or nothing clump [2].

2
18.2 Command Design Pattern

18.2.1 Identification
Name Classification Strategy
Command Behavioural Delegation
Intent
Encapsulate a request as an object, thereby letting you parameterise clients with
different requests, queue or log requests, and support undoable operations.
([1]:263)
18.2.2 Problem
Used to modify existing interfaces to make it work after it has been designed.

18.2.3 Structure

Figure 1: The structure of the Command Design Pattern

18.2.4 Participants
Command

• declares an interface for executing an operation.

ConcreteCommand

• defines a binding between a Receiver object and an action.

• implements execute() by invoking the corresponding operation(s) on Receiver.
Client (Application)

• creates a ConcreteCommand object and sets its receiver.

Invoker

• asks the command to carry out the request.

1
Receiver

• knows how to perform the operations associated with carrying out a request.
Any class may serve as a Receiver.

2
19.2 Adapter Design Pattern

19.2.1 Identification
Name Classification Strategy
Adapter Structural Inheritance (Class) and
Delegation (Object)
Intent
Convert an interface of a class into another interface clients expect. Adapter lets
classes work together that couldn’t otherwise because of incompatible interfaces.
([2]:139)
19.2.2 Problem
Used to modify existing interfaces to make it work after it has been designed.

19.2.3 Structure
The Adapter design pattern is the only pattern to which one of two structures can be
applied. The pattern can either make use of delegation or inheritance to achieve its intent.
The delegation structure is referred to as an Object Adapter, Figure 1, and the inheritance
structure as shown in Figure 2 for the Class Adapter.

Figure 1: The structure of the Object Adapter Design Pattern

1
 Figure 2: The structure of the Class Adapter Design Pattern

19.2.4 Participants
Adaptee

• The existing interface that needs to be adapted

Target

• Domain specific interface used by the client

Adapter

• Adapts the interface of Adaptee to the Target interface

Client

• Manipulates objects conforming to the interface specified by the abstract class

Target

2
22.2 Builder Design Pattern

22.2.1 Identification
Name Classification Strategy
Builder Creational Delegation
Intent
Separate the construction of a complex object from its representation so that the
same construction process can create different representations. ([1]:97)
22.2.2 Structure

Figure 1: The structure of the Builder Design Pattern

22.2.3 Participants
Builder

• specifies an abstract interface for creating parts of a Product object.

Concrete Builder

• constructs and assembles parts of the product by implementing the Builder

interface.
• defines and keeps track of the representation it creates.
• provides an interface for retrieving the product

1
Director

• constructs an object using the Builder interface.

Product

• represents the complex object under construction. ConcreteBuilder builds the

product’s internal representation and defines the process by which it’s
assembled.
• includes classes that define the constituent parts, including interfaces for
assembling the parts into the final result.

22.2.4 Problem
An application maintains a complex aggregate and provide for the construction of different
representations of the aggregate. There is a need to design the application in such a way
that the addition of more representations of the aggregate would require minimal
modification of the application.

2
23.2 Interpreter Design Pattern

23.2.1 Identification
Name Classification Strategy
Interpreter Behavioural Inheritance
Intent
Given a language, define a represention for its grammar along with aninterpreter
that uses the representation to interpret sentences in thelanguage. ([2]:243)
23.2.2 Structure

Figure 1: The structure of the Interpreter Design Pattern

23.2.3 Participants
AbstractExpression

• declares an abstract Interpret operation that is common to all nodes in the

abstract syntax tree.
TerminalExpression

• implements an Interpret operation associated with terminal symbols in the

grammar.
• an instance is required for every terminal symbol in a sentence.

1
NonterminalExpression

• one such class is required for every rule R ::= R1 R2 ... Rn in the grammar.
• maintains instance variables of type AbstractExpression for each of the
symbols R1 through Rn.
• implements an Interpret operation for nonterminal symbols in the grammar.
Interpret typically calls itself recursively on the variables representing R1
through Rn.
Context

• contains information that’s global to the interpreter.

Client

• builds (or is given) an abstract syntax tree representing a particular sentence

in the language that the grammar defines. The abstract syntax tree is assembled
from instances of the NonterminalExpression and TerminalExpression classes.
• invokes the Interpret operation.

23.2.4 Problem
A class of problems occurs repeatedly in a well-defined and well-understood domain. If
the domain were characterized with a language that can be expressed in terms of a formal
grammar, then problems could be easily solved with an interpretation engine
representing the grammar. [3].

2
24.2 Bridge Design Pattern

24.2.1 Identification
Name Classification Strategy
Bridge Structural Delegation
Intent
Decouple an abstraction from its implementation so that the two can vary
independently ([2]:151)
24.2.2 Structure

Figure 1: The structure of the Bridge Design Pattern

24.2.3 Participants
Abstraction

• defines the abstraction’s interface.

• maintains a reference to an object of type Implementor.

Refined Abstraction

• Extends the interface defined by Abstraction.

1
Implementor

• defines the interface for implementation classes. This interface doesn’t have to
correspond exactly to Abstraction’s interface; in fact the two interfaces can be
quite different. Typically the Implementor interface provides only primitive
operations, and Abstraction defines higher-level operations based on these
primitives.

Concrete Implementor

• implements the Implementor interface and defines its concrete

implementation.

24.2.4 Problem
A system has a proliferation of classes resulting from a coupled interface and numerous
implementations [4].