Author: RAMU MEDA
- Also known as
- Provide a way to
access the elements of an aggregate object sequentially without exposing
its underlying representation.
- To traverse the aggregate
in different ways, depending on what you want to accomplish.
- to have more than
one traversal pending on the same aggregate object
- The key idea in
this pattern is to take the responsibility for access and traversal out of
the aggregate object and put it into an iterator object
- The Iterator class
defines an interface for accessing the aggregate’s elements.
- An iterator object
is responsible for keeping track of the current element; that is, it knows
which elements have been traversed already.
- Separating the
traversal mechanism from the List object lets us define iterators for
different traversal policies without enumerating them in the List
interface. For example, FilteringListIterator might provide access only to
those elements that satisfy specific filtering constraints.
- Use the Iterator pattern
- to access an aggregate object's
contents without exposing its
- to support multiple traversals of aggregate
- to provide a uniform interface for traversing
different aggregate structures (that is, to support polymorphic
- The Iterator
pattern has three important consequences:
- It supports
variations in the traversal of an aggregate. Complex aggregates may be
traversed in many ways. For example, code generation and semantic
checking involve traversing parse trees. Code generation may traverse the
parse tree inorder or preorder. Iterators make it easy to change the
traversal algorithm: Just replace the iterator instance with a different one. You
can also define Iterator subclasses to support new traversals.
- Iterators simplify the Aggregate interface. Iterator's
traversal interface obviates the need for a similar interface in
Aggregate, thereby simplifying the aggregate's interface.
- More than one
traversal can be pending on an aggregate. An iterator keeps track of its
own traversal state. Therefore you can have more than one traversal in progress at once.
- external iterator / Active iterator à client controls the iteration à Clients that use an external
iterator must advance the traversal and request the next element
explicitly from the iterator à more flexible e.g.: easy to
compare two collections for equality
- Internal iterator / Passive Iteratorà the iterator controls iteration. à The client hands
an internal iterator an operation to perform, and the iterator applies
that operation to every element in the aggregate. à easier to use, because they
define the iteration logic for you.
- It’s easier just to
use an internal
iterator (rather than external iterator) for recursive aggregate structures like composite. It can record the
current position simply by calling itself recursively, thereby storing the
path implicitly in the call stack.
- Cursor à iterator to store just the
state of the iteration. It merely points to the current position in the
aggregate à aggregate defines the
- Cursors are a simple example of the
Memento pattern and share many of its implementation issues.
- Why Cursor?? à If the iterator is
responsible for the traversal algorithm, then it's easy to use different
iteration algorithms on the same aggregate, and it can also be easier to
reuse the same algorithm on different aggregates. On the other hand, the
traversal algorithm might need to access the private variables of the
aggregate. If so, putting the traversal algorithm in the iterator violates
the encapsulation of the aggregate.
- Robust iterator à ensures that insertions and
removals won't interfere with traversal, and it does it without copying
- NullIterator à is a degenerate iterator
that's helpful for handling boundary conditions. By definition, a NullIterator is always done
with traversal; that is, its IsDone operation always evaluates to true.
- Composite: Iterators are often applied
to recursive structures such as Composites.
- Factory Method: Polymorphic
iterators rely on factory methods to instantiate the appropriate Iterator
- Memento : is often used in
conjunction with the Iterator pattern. An iterator can use a memento to
capture the state of an iteration. The iterator stores the memento internally.
- Define an object
that encapsulates how
a set of objects interact.
- promotes loose coupling by keeping objects from
referring to each other explicitly, and it lets you vary their interaction independently
- Colleagues send and receive requests
from a Mediator object.
- The mediator
implements the cooperative behavior by routing requests between the
- It limits subclassing. A mediator
localizes behavior that otherwise would be distributed among several
objects. Changing this behavior requires subclassing Mediator only;
Colleague classes can be reused as is.
- It decouples colleagues. A mediator
promotes loose coupling between colleagues. You can vary and reuse
Colleague and Mediator classes independently.
- It simplifies object protocols. A mediator
replaces many-to-many interactions with one-to-many interactions between
the mediator and its colleagues. One-to-many relationships are easier to
understand, maintain, and extend.
- It abstracts how objects cooperate. Making mediation
an independent concept and encapsulating it in an object lets you focus on
how objects interact apart from their individual behavior. That can help
clarify how objects interact in a system.
- It centralizes control. The Mediator
pattern trades complexity of interaction for complexity in the mediator.
Because a mediator encapsulates protocols, it can become more complex than
any individual colleague. This can make the mediator itself a monolith
that's hard to maintain.
- Facade differs from
Mediator in that it abstracts a subsystem of objects to provide a more
convenient interface. Its protocol is unidirectional; that is, Facade objects make
requests of the subsystem classes but not vice versa. In contrast,
Mediator enables cooperative behavior that colleague objects don't or
can't provide, and the protocol is multidirectional.
- Colleagues can communicate with the
mediator using the Observer pattern.
Colleagues have to communicate with their mediator when an event of
interest occurs. One approach is to implement the Mediator as an Observer using the Observer
classes act as Subjects, sending notifications to the mediator whenever they
change state. The mediator responds by propagating the effects of the
change to other colleagues
- There's no need to
define an abstract
Mediator class when colleagues work with only one mediator. The
abstract coupling that the Mediator class provides lets colleagues work
with different Mediator subclasses, and vice versa
- Provide a unified interface to a set of interfaces in a subsystem.
- defines a higher-level interface that makes the subsystem easier to use
- Provides a single, simplified interface to the more
general facilities of a subsystem.
- Clients communicate
with the subsystem by sending requests to Facade, which forwards them to
the appropriate subsystem object(s).
- Although the
subsystem objects perform the actual work, the facade may have to do work
of its own to translate its interface to subsystem interfaces.
- Clients that use
the facade don't have to access its subsystem objects directly.
Knows which subsystem classes are responsible for a
Delegates client requests to appropriate subsystem objects.
Implement subsystem functionality.
Handle work assigned by the Facade object.
no knowledge of the facade; that is, they keep no references to it.
- The Facade pattern
offers the following benefits:
- It shields clients
from subsystem components, thereby reducing the number of objects that clients deal
and making the subsystem easier to use.
- It promotes weak
coupling between the subsystem and its clients. Often the components in a
subsystem are strongly coupled. Weak coupling lets you vary the
components of the subsystem without affecting its clients. Facades help
layer a system and the dependencies between objects. They can eliminate complex or circular
dependencies. This can be an important consequence when the
client and the subsystem are implemented independently.
- Reducing compilation dependencies is vital in large
software systems. You want to save time by minimizing recompilation when
subsystem classes change. Reducing compilation dependencies with facades
can limit the recompilation needed for a small change in an important
subsystem. A facade can also simplify porting systems to other platforms,
because it's less likely that building one subsystem requires building
- It doesn't prevent applications from
using subsystem classes if they need to. Thus you can choose between
ease of use and generality.
- Use the Facade
You want to provide a simple interface to a complex subsystem. Subsystems often get
more complex as they evolve. Most patterns, when applied, result in more and
smaller classes. This makes the subsystem more reusable and easier to
customize, but it also becomes harder to use for clients that don't need to
customize it. A facade can
provide a simple default view of the subsystem that is good enough for most
clients. Only clients needing more customizability will need to look beyond the
There are many dependencies between clients and the
implementation classes of an abstraction. Introduce a facade to decouple the subsystem from clients and
other subsystems, thereby promoting subsystem independence and portability.
You want to
layer your subsystems. Use a facade
to define an entry point to each subsystem level. If subsystems are
dependent, then you can simplify the dependencies between them by making them
communicate with each other solely through their facades.
can be used with Facade to provide an interface for creating subsystem objects
in a subsystem-independent way. Abstract Factory can also be used as an
alternative to Facade to hide platform-specific classes.
Mediator is similar to Facade in
that it abstracts
functionality of existing classes. However, Mediator's purpose is to abstract
arbitrary communication between colleague objects, often centralizing functionality that doesn't
belong in any one of them. A mediator's colleagues are aware of and communicate with
the mediator instead of communicating with each other directly. In contrast, a facade merely abstracts the interface to
subsystem objects to make them easier to use; it doesn't define new functionality, and subsystem classes don't know about it.
Usually only one Facade object is required. Thus Facade
objects are often Singletons .
- Also Known As Dependents, Publish-Subscribe
- Define a one-to-many dependency between objects so
that when one object changes state, all its dependents are notified and
- Maintain consistency between related objects by making the
coupled, because that increases their reusability.
- Abstract coupling between Subject and
Observer. All a subject knows is that it has a list of observers, each
conforming to the simple interface of the abstract Observer class. The
subject doesn't know the concrete class of any observer. Thus the coupling
between subjects and observers is abstract and minimal. Because
Subject and Observer aren't tightly coupled, they can belong to different
layers of abstraction in a system. A lower-level subject can communicate
and inform a higher-level observer, thereby keeping the system's layering
- Support for broadcast communication. Unlike an ordinary
request, the notification that a subject sends needn't specify its
receiver. The notification is broadcast automatically to all interested objects that subscribed
The subject doesn't care how many interested objects exist; its only
responsibility is to notify its observers. This gives you the freedom to
add and remove observers at any time. It's up to the observer to handle or
ignore a notification.
updates. Because observers have no knowledge of each other's presence,
they can be blind to the ultimate cost of changing the subject. A
seemingly innocuous operation on the subject may cause a cascade of
updates to observers and their dependent objects. Moreover, dependency
criteria that aren't well-defined or maintained usually lead to spurious
updates, which can be hard to track down.
- Use the Observer
pattern in any of the following situations:
- When an
abstraction has two aspects, one dependent on the other. Encapsulating
these aspects in separate objects lets you vary and reuse them independently.
- When a change to
one object requires changing others, and you don't know how many objects need to be changed.
- When an object
should be able to notify
other objects without making assumptions about who these objects are. In other words,
you don't want these objects tightly coupled.
- Specify the kinds of objects to create using a
prototypical instance, and create new objects by copying this prototype.
- Prototype à declares an interface for cloning itself.
- ConcretePrototype à implements an operation for cloning itself.
- Client à creates a new object by asking a prototype to clone itself.
- A client can install and remove prototypes at run-time.
- Specifying new objects by varying
values. Highly dynamic systems let you define new behavior through object composition—by specifying
values for an object's variables, for example—and not by defining new
classes. You effectively define new kinds of objects by instantiating
existing classes and registering the instances as prototypes of client
objects. A client can exhibit new behavior by delegating responsibility to
the prototype. This kind of design lets users define new
"classes" without programming. In fact, cloning a prototype is
similar to instantiating a class. The Prototype pattern can greatly reduce
the number of classes a system needs.
- Specifying new objects by varying
structure. Many applications build objects from parts and subparts. Editors
for circuit design, for example, build circuits out of subcircuits.1 For
convenience, such applications often let you instantiate complex,
user-defined structures, say, to use a specific subcircuit again and
again. The Prototype pattern supports this as well. We simply add this
subcircuit as a prototype to the palette of available circuit elements. As
long as the composite circuit object implements Clone as a deep copy,
circuits with different structures can be prototypes.
- Reduced subclassing. Factory Method
often produces a hierarchy of Creator classes that parallels the product
class hierarchy. The
Prototype pattern lets you clone a prototype instead of asking a factory
method to make a new object. Hence you don't need a Creator class hierarchy at all.
- Configuring an application with
classes dynamically. Some run-time environments let you load classes into
an application dynamically
- Use the Prototype
- when a system should be independent of how
its products are created, composed, and represented; and
- when the classes
to instantiate are specified at run-time, for example, by dynamic
loading; or to avoid building a class hierarchy of factories that
parallels the class hierarchy of products; or
- When instances of a class can have
one of only a few different combinations of state. It may be more
convenient to install a corresponding number of prototypes and clone them
rather than instantiating the class manually, each time with the
- The main liability of the Prototype
pattern is that
- Each subclass of Prototype must
implement the Clone operation, which may be difficult. For example,
adding Clone is difficult when the classes under consideration already
- Implementing Clone
can be difficult when their internals include objects that don't support copying or have
- Prototype and Abstract Factory are competing
patterns in some ways, as we discuss at the end of this chapter. They can
also be used together, however. An Abstract Factory might store a set of
prototypes from which to clone and return product objects.
- Designs that make
heavy use of the Composite and Decorator patterns often can benefit from
Prototype as well.
- Also Known As surrogate
- Intent à Provide a surrogate or placeholder for another object
to control access to it.
- One reason for
controlling access to an object is to defer the full cost of its creation and
initialization until we actually need to use it.
- Proxy is applicable
whenever there is a need for a more versatile or sophisticated reference to an
object than a simple pointer.
- Remote proxy à also called Ambassador à provides a local
representative for an object in a different address space.
- Remote proxy can
hide the fact that an object resides in a different address space.
- Virtual proxy à creates expensive objects on
- Protection proxy à controls access to the
original object. Protection proxies are useful when objects should have
different access rights.
- Smart reference à is a replacement for a bare
pointer that performs additional actions when an object is accessed.
Typical uses include
- Counting the number of references to the real
object so that it can be freed automatically when there are no more
references (also called smart
- Loading a
persistent object into
memory when it's first referenced.
- Checking that the
real object is locked before it's
accessed to ensure that no other object can change it.
- Both protection proxies and smart
references allow additional housekeeping tasks when an object is accessed.
- Provides an interface identical to Subject's so that a proxy
can by substituted for the real subject.
- Controls access to
the real subject and may be responsible for creating and deleting it.
- Proxy forwards requests to RealSubject when appropriate,
depending on the kind of proxy.
- copy-on-write à related to
creation on demand à another optimization that the Proxy pattern can hide
from the client. à Copying a large and complicated object only if it is by using proxy.
- Vs Adapter à an adapter provides a different interface to the object it
adapts. In contrast, a proxy provides the same interface as its subject. However, a proxy
used for access protection might refuse to perform an operation that the
subject will perform, so its interface may be effectively a subset of the
- Vs Decorator à although decorators can have
similar implementations as proxies, decorators have a different purpose. A decorator adds one or more
responsibilities to an object, whereas a proxy controls access to an
- Proxies vary in the
degree to which they are implemented like a decorator. A protection proxy might be
implemented exactly like a decorator.
- On the other hand,
a remote proxy will
not contain a direct reference to its real subject but only an
indirect reference, such as "host ID and local address on host."
A virtual proxy will
start off with an indirect reference such as a file name but will
eventually obtain and use a direct reference.
Also Known As Wrapper ( Decorator is also
known as Wrapper )
Intent à to convert the interface of a class into another
interface clients expect.
Adapter lets classes work together that couldn't otherwise
because of incompatible
Target à defines the domain-specific
interface that Client uses.
Client à collaborates with objects conforming to the Target interface.
Adaptee à defines an existing interface that needs adapting.
Adapter à adapts the interface of Adaptee to the Target interface.
Clients call operations on an Adapter instance. In turn,
the adapter calls Adaptee operations that carry out the request.
Use the Adapter pattern when
to use an existing class, and its interface does not match the one you need.
You want to
create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that
don't necessarily have compatible interfaces.
(Object adapter only) you need to use several existing
subclasses, but it's impractical to adapt their interface by subclassing every
one. An object adapter can
adapt the interface of its parent class.
Vs Bridge has a structure similar to an
object adapter, but Bridge has a different intent: It is meant to separate an
interface from its implementation so that they can be varied easily and
independently. An adapter is meant to change the interface of an existing
Vs Decorator enhances another object
without changing its
A decorator is thus more transparent to the application than an adapter
is. As a consequence, Decorator
supports recursive composition, which isn't possible with pure adapters.
Vs Proxy defines a
representative or surrogate for another object and does not change its interface
Adapts Adaptee to Target by committing to a concrete Adapter class. As a consequence, a
class adapter won't work when we want to adapt a class
and all its subclasses.
Lets Adapter override some of Adaptee's behavior, since Adapter is a subclass of
only one object and no additional pointer indirection is needed to get to the adaptee.
Lets a single
Adapter work with many Adaptees that is, the Adaptee itself and all of its
subclasses (if any). The Adapter can also add functionality to all Adaptees at once.
Makes it harder
to override Adaptee behavior. It will require subclassing Adaptee and making Adapter refer
to the subclass rather than the Adaptee itself.
à classes with built-in interface adaptation à a class is more reusable when you
minimize the assumptions other classes must make to use it. à
Interface adaptation lets us incorporate our class into existing systems
that might expect different interfaces to the class.
adapters à to provide transparency à an adapted object no longer conforms to the Adaptee interface, so it
can't be used as is wherever an Adaptee object can. Two-way adapters can
provide such transparency. à Specifically, they're useful when two different clients need to
view an object differently.
- Compose objects
into tree structures to represent part-whole hierarchies.
- Composite lets clients treat individual objects and
compositions of objects uniformly using recursive composition.
- Defines class hierarchies consisting of
primitive objects and composite objects. Primitive objects can be composed
into more complex objects, which in turn can be composed, and so on
recursively. Wherever client code expects a primitive object, it can also
take a composite object.
- Makes the client simple. Clients can treat
composite structures and individual objects uniformly. Clients normally
don't know (and shouldn't care) whether they're dealing with a leaf or a
composite component. This simplifies client code, because it avoids having
to write tag-and-case-statement-style functions over the classes that
define the composition.
- Makes it easier to add new kinds of components. Newly defined
Composite or Leaf subclasses work automatically with existing structures
and client code. Clients don't have to be changed for new Component
- Can make your design overly general. The disadvantage
of making it easy to add new components is that it makes it harder to restrict the components of a
composite. Sometimes you want a composite to have only certain components.
With Composite, you can't rely on the type system to enforce those
constraints for you. You'll have to use run-time checks instead.
Clients use the Component class
interface to interact with objects in the composite structure. If the recipient
is a Leaf, then the request is handled directly. If the recipient is a
Composite, then it usually forwards requests to its child components, possibly
performing additional operations before and/or after forwarding
- declares the interface
for objects in the composition.
default behavior for the interface common to all classes, as
- declares an
interface for accessing and managing its child components.
defines an interface for accessing a component's parent in the recursive
structure, and implements it if that's appropriate.
- represents leaf
objects in the composition. A leaf has no children.
- defines behavior
for primitive objects in the composition.
- defines behavior
for components having children.
- stores child
child-related operations in the Component interface.
- Client à manipulates objects in the
composition through the Component interface.
- Often the
component-parent link is used for a Chain of Responsibility.
- Decorator is often used with Composite.
When decorators and composites are used together, they will usually have a
common parent class. So decorators will have to support the Component
interface with operations like Add, Remove, and GetChild.
- Flyweight lets you share components,
but they can no longer refer to their parents.
- Iterator can be used to traverse
- Visitor localizes operations and
behavior that would otherwise be distributed across Composite and Leaf
- Also Known As Action, Transaction
- Intent à Encapsulate a request as an object, thereby letting
clients with different requests, queue or log requests, and support undoable operations.
- To issue requests
to objects without knowing anything about the operation being requested or
the receiver of the request.
- Command decouples the object that invokes the
operation from the one that knows how to perform it. i.e. decouple invoker from receiver
- Commands are first-class objects. They can be
manipulated and extended like any other object.
- You can assemble
commands into a composite
command.. In general, composite commands are an instance of the
- It's easy to add new Commands, because you
don't have to change existing classes.
- Use the Command
pattern when you want to
- Parameterize objects by an action to
perform.. Commands are an object-oriented replacement for callbacks.
- Specify, queue, and execute requests
at different times. A Command object can have a lifetime independent of
the original request. If the receiver of a request can be represented in
an address space-independent way, then you can transfer a command object
for the request to a different process and fulfill the request there.
- Support undo. The Command's Execute
operation can store state for reversing its effects in the command
itself. The Command interface must have an added Unexecute operation that
reverses the effects of a previous call to Execute. Executed commands are
stored in a history list. Unlimited-level undo and redo is achieved by
traversing this list backwards and forwards calling Unexecute and
- Support logging changes so that they can
be reapplied in case of a system crash. By augmenting the Command interface with load and
store operations, you can keep a persistent log of changes. Recovering
from a crash involves reloading logged commands from disk and reexecuting
them with the Execute operation.
- Structure a system around high-level
operations built on primitives operations. Such a structure is common
in information systems that support transactions. A transaction
encapsulates a set of changes to data. The Command pattern offers a way
to model transactions. Commands have a common interface, letting you
invoke all transactions the same way. The pattern also makes it easy to
extend the system with new transactions.
The client creates a ConcreteCommand object and specifies its receiver.
An Invoker object stores the
The invoker issues a request by calling Execute on the command. When commands are
undoable, ConcreteCommand stores state for undoing the command prior to invoking
The ConcreteCommand object invokes operations on its
receiver to carry out the request.
Command decouples the invoker from the receiver (and the
request it carries out).
Command à declares an interface for executing an operation.
- Defines a
binding between a Receiver object and an action.
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
knows how to perform the operations associated with carrying out a
request. Any class may serve as a Receiver.
- A Composite can be used to implement MacroCommands.
- A Memento can keep state the command
requires to undo its effect.
- A command that must
be copied before being placed on the history list acts as a Prototype
- Also Known As Handle/Body
- Decouple an abstraction from its
implementation so that the two can vary independently.
- Inheritance binds an implementation to
the abstraction permanently, which makes it difficult to modify, extend,
and reuse abstractions and implementations independently
- Use the Bridge pattern when
- You want to avoid a permanent binding between an
abstraction and its implementation. This might be the case, for
example, when the implementation must be selected or switched at
- Both the abstractions and their
implementations should be extensible by subclassing. In this case,
the Bridge pattern lets you combine the different abstractions and
implementations and extend them independently.
- Changes in the implementation of an
abstraction should have no impact on clients; that is, their code should
not have to be recompiled.
- You want to share an implementation among
multiple objects (perhaps using reference counting), and this fact
should be hidden from the client.
- Abstraction forwards client
requests to its Implementor object.
- Decoupling interface and
implementation. An implementation is not bound permanently to an
interface. The implementation of an abstraction can be configured at
run-time. It's even possible for an object to change its implementation
Abstraction and Implementor also eliminates compile-time dependencies on the
implementation. Changing an implementation class doesn't require
recompiling the Abstraction class and its clients. This property is
essential when you must ensure binary compatibility between different
versions of a class library.
- Furthermore, this decoupling encourages layering
that can lead to a better-structured system. The high-level part of a
system only has to know about Abstraction and Implementor.
- Improved extensibility. You can extend
the Abstraction and Implementor hierarchies independently.
- Hiding implementation details from
clients. You can shield clients from implementation details, like the sharing of implementor objects and the accompanying reference count mechanism (if
- An Abstract Factory can create and
configure a particular Bridge.
- The Adapter pattern is geared toward making
unrelated classes work together. It is usually applied to systems after they're designed. Bridge, on the other hand, is used up-front in a design to let
abstractions and implementations vary independently.
- Intent à Use sharing to support large numbers of fine-grained objects efficiently.
- A flyweight is a shared object that can be used in multiple contexts
- The flyweight acts
as an independent
object in each context—it's indistinguishable from an instance of the object
that's not shared.
- Flyweights cannot
make assumptions about the context in which they operate.
- Intrinsic state à stored in the flyweight à information that's
independent of the flyweight's context à sharable.
- Extrinsic state à depends on and varies with the flyweight's context àcan't be shared. à Client objects are
responsible for passing extrinsic state to the flyweight when it needs it.
- Flyweights model concepts or entities that are normally
too plentiful to represent with objects.
- The Flyweight
pattern's effectiveness depends heavily on how and where it's used. Apply
the Flyweight pattern when all of the following are true:
- An application
uses a large number
- Storage costs are high because of the
sheer quantity of objects.
- Most object state can be made
- Many groups of objects may be
replaced by relatively few shared objects once extrinsic state is removed.
- The application doesn't depend on object identity. Since flyweight
objects may be shared, identity tests will return true for conceptually
- Savings = f
(flyweights no. + amt of intrinsic state + amt of extrinsic state +
extrinsic stored/computed )
- The more flyweights
are shared, the greater the storage savings. The savings increase with the
amount of shared state.
- The greatest savings occur when the
objects use substantial quantities of both intrinsic and extrinsic state,
and the extrinsic state can be computed rather than stored. Then you save on
storage in two ways: Sharing
reduces the cost of intrinsic state, and you trade extrinsic state for
- Because objects are
shared, clients shouldn't instantiate them directly. FlyweightFactory lets clients locate a particular flyweight.
objects often use an associative
to let clients look up flyweights of interest
- Sharability also
implies some form of reference
counting or garbage collection to reclaim a flyweight's
storage when it's no longer needed.
- Related Patterns:
- The Flyweight
pattern is often combined with the Composite pattern to implement a logically
hierarchical structure in terms of a directed-acyclic graph with shared leaf nodes.
- It's often best to
implement State and
Strategy objects as flyweights.
- Also Known As Token
- Intent à Without violating encapsulation, capture and externalize an object's
internal state so that the object can be restored to this state later.
- A memento is an object that stores a snapshot of the internal
state of another object—the memento's originator.
- The undo mechanism
will request a memento from the originator when it needs to checkpoint the
originator's state. The originator initializes the memento with
information that characterizes its current state. Only the originator can store and
retrieve information from the memento—the memento is "opaque" to
- Use the Memento
- a snapshot of
(some portion of) an object's state must be saved so that it can be
restored to that state later, and
- a direct interface
to obtaining the state would expose implementation details and break the
stores internal state of the Originator object. The memento
may store as much or as little of the originator's internal state as necessary
at its originator's discretion.
protects against access by objects other than the
originator. Mementos have effectively two interfaces. Caretaker sees a narrow interface to the Memento—it can only pass
the memento to other objects. Originator, in contrast, sees a wide interface, one that lets it access all the
data necessary to restore itself to its previous state. Ideally, only the
originator that produced the memento would be permitted to access the memento's
creates a memento containing a snapshot of its current
uses the memento to restore its internal state.
is responsible for the memento's safekeeping.
operates on or examines the contents of a memento.
A caretaker requests a memento from an originator, holds it
for a time, and passes it back to the originator, as the following interaction
Sometimes the caretaker won't pass the memento back to the
originator, because the originator might never need to revert to an earlier
Mementos are passive. Only the originator that created a memento will assign or retrieve
The Memento pattern has several consequences:
encapsulation boundaries. Memento avoids exposing information that only an
originator should manage but that must be stored nevertheless outside the
originator. The pattern shields other objects from potentially complex
Originator internals, thereby preserving encapsulation boundaries.
simplifies Originator. In other encapsulation-preserving designs, Originator
keeps the versions of internal state that clients have requested. That puts all
the storage management burden on Originator. Having clients manage the state
they ask for simplifies Originator and keeps clients from having to notify
originators when they're done.
mementos might be expensive. Mementos might incur considerable overhead if Originator
must copy large amounts of information to store in the memento or if clients
create and return mementos to the originator often enough. Unless encapsulating
and restoring Originator state is cheap, the pattern might not be appropriate.
narrow and wide interfaces. It may be difficult in some languages to ensure that only
the originator can access the memento's state.
costs in caring for mementos. A caretaker is responsible for deleting the mementos it
cares for. However, the caretaker has no idea how much state is in the memento.
Hence an otherwise lightweight caretaker might incur large storage costs when
it stores mementos.
Command : Commands can use
mementos to maintain state
for undoable operations.
Iterator : Mementos can be used