Software Engineering II

Command & Memento Patterns

Dr. Abeer Hamdy

Command Pattern

➢ Intent
▪ Command is a behavioral design pattern that turns a request into a
stand-alone object that contains all information about the request. This
transformation lets you parameterize methods with different requests,
delay or queue a request’s execution, and support undoable operations.

▪ Command decouples the object that invokes the operation from the one
that know how to perform it.
 Command Pattern-Real world Analogy
➢ Meal order at a restaurant:
▪ waiter takes your order, writing it down on a piece of paper. The waiter goes to the kitchen
and sticks the order on the wall. After a while, the order gets to the cook, who reads it and
cooks the meal accordingly. The paper order serves as a command which is encapsulated in
the paper. It remains in a queue until the cook is ready to serve it. The order contains all the
relevant information required to cook the meal. It allows the cook to start cooking right
away instead of running around clarifying the order details from you directly. The cook is in
charge for cooking the order not the waitress.
Command Pattern Structure
Command Pattern Structure
 Command Pattern Structure
➢ The classes participating in the pattern are:
▪ Command - declares an interface for executing an operation;
▪ ConcreteCommand - extends the Command interface, implementing the
Execute method by invoking the corresponding operations on Receiver. It
defines a link between the Receiver and the action.
▪ Client - creates a ConcreteCommand object and sets its receiver;
▪ Invoker - asks the command to carry out the request;
▪ Receiver - knows how to perform the operations;

The Client asks for a command to be executed. The Invoker takes the command,
encapsulates it and places it in a queue, in case there is something else to do first,
and the ConcreteCommand that is in charge of the requested command, sending
its result to the Receiver.

➢ Important note:
▪ Avoid having the command implements everything itself, without sending
anything to the receiver. We must always keep in mind the fact that the
receiver is the one who knows how to perform the operations needed, the
purpose of the command being to help the client to delegate its request quickly
and to make sure the command ends up where it should.
Command Pattern Example #1

➢ Command toolkit: A menu in a text editor application where

users can perform various tasks such as open, copy, paste, etc.

Source: Design Patterns: Elements of Reusable Object-Oriented Software

Command Pattern Example #1

➢ Command toolkit
Command Pattern Example #1

➢ Command toolkit
Command Pattern Example #1

➢ Command + Composite patterns for Macro Commands.

Command related patterns

➢ Composite
▪ we can use the composite pattern to group existing commands in another
new command. This way, macros can be created from existing
commands.
➢ Memento
▪ You can use Command and Memento together when implementing
“undo”. In this case, commands are responsible for performing various
operations over a target object, while mementos save the state of that
object just before a command gets executed.
➢ Strategy
▪ Command and Strategy may look similar because you can use both to
parameterize an object with some action. However, they have very
different intents.
 Command Pattern

➢ Undo and redo actions

▪ Some implementations of the Command design pattern include parts for
supporting undo and redo of actions. In order to do that a mechanism to obtain
past states of the Receiver object is needed; in order to achieve this there are two
options:
• Before running each command a snapshot of the receiver state is stored in
memory. This does not require much programming effort but can not be
always applied. For example doing this in an image processing application
would require storing images in memory after each step, which is practically
impossible.
• Instead of storing receiver objects states, the set of performed operations are
stored in memory. In this case the command and receiver classes should
implement the inverse algorithms to undo each action. This will require
additional programming effort, but less memory will be required. Sometimes
for undo/redo actions the command should store more information about the
state of the receiver objects.
• A good idea in such cases is to use the Memento Pattern.
Command Pattern

➢ Applicability
▪ Use the Command pattern when you want to queue operations, schedule their
execution, or execute them remotely.
▪ Use the Command pattern when you want to implement reversible operations.
➢ Pros
▪ The main advantage of the command design pattern is that it decouples the
object that invokes the operation from the one that know how to perform it.
▪ Open/Closed Principle. You can introduce new commands into the app without
breaking existing client code.
▪ You can implement undo/redo.
▪ You can assemble a set of simple commands into a complex one.

➢ Cons
▪ The code may become more complicated since you’re introducing a whole
new layer between senders and receivers.
Memento Pattern

➢ Motivation
▪ It is sometimes necessary to capture the internal state of an object at
some point and have the ability to restore the object to that state later in
time. Such a case is useful in case of error or failure or undo.

➢ Intent
▪ The intent of this pattern is to capture the internal state of an object
without revealing the details of its implementation (without violating
encapsulation) and thus providing a mean for restoring the object into
initial state when needed.
Memento Pattern Class diagram #1

Design based on nested classes

Memento Pattern
➢ Memento
▪ Stores internal state of the Originator object. The state can include any number
of state variables.
▪ Memento may include other attributes related to the metadata of the memento.
▪ The Memento must have two interfaces, an interface to the caretaker. This
interface must not allow any operations or any access to internal state stored
by the memento and thus honors encapsulation. The other interface is to the
originator and allows the originator to access any state variables necessary for
the originator to restore previous state.
➢ Originator
▪ Creates a memento object capturing the originator’s internal state.
▪ Use the memento object to restore its previous state.
➢ Caretaker
▪ Responsible for keeping the mementos.
▪ The memento is opaque to the caretaker, and the caretaker must not operate on
it.
▪ Caretaker does not have access to the state of the memento but it can access
the memento meta data like the date and time of creation of a memento.
Memento Pattern

Sequence diagram
Memento Pattern Examples

➢ Undo operation (like undoing calculator operation).

➢ Databases transactions.
▪ Transactions are operations on the database that occur in an atomic,
consistent, durable, and isolated fashion. A transaction can contain multiple
operations on the database; each operation can succeed or fail, however a
transaction guarantees that if all operations succeed, the transaction would
commit and would be final. And if any operation fails, then the transaction
would fail and all operations would rollback and leave the database as if
nothing has happened. This mechanism of rolling back uses the memento
design pattern. Consider an object representing a database table, a
transaction manager object which is responsible of performing transactions
must perform operations on the table object while having the ability to undo
the operation if it fails, or if any operation on any other table object fails. To
be able to rollback, the transaction manager object would ask the table object
for a memento before performing an operation and thus in case of failure, the
memento object would be used to restore the table to its previous state.
Memento Pattern structure #2
Memento Related Patterns

➢ Command
▪ You can use Command and Memento together when implementing
“undo”. In this case, commands are responsible for performing various
operations over a target object, while mementos save the state of that
object just before a command gets executed.
▪ Command acts as a caretaker , to keep a snap shot of the originator
object before executing the command.
Memento Pattern Pros and Cons

➢ Pros
▪ You can produce snapshots of the object’s state without violating its
encapsulation
▪ You can simplify the originator’s code by letting the caretaker maintain
the history of the originator’s state (Promotes SRP principle)

➢ Cons
▪ The app might consume lots of RAM if clients create mementos too
often.
▪ Caretakers should track the originator’s lifecycle to be able to destroy
obsolete mementos.
References

➢ https://refactoring.guru/design-patterns

➢ https://www.oodesign.com/command-pattern.html

➢ “Head First Design Patterns”, By: Freeman and Freeman,

O'Reilly,2004

➢ “Design Patterns: Elements of Reusable Object-Oriented

Software”, By : Gamma, Helm, Johnson and Vlissides, addison-
Wesley, 1995