Linzhang Wang

1
The Command Pattern

• Linzhang Wang
• Dept. of Computer SciTech,
• Nanjing University

2
Intent

• Encapsulate a request as an object, thereby
  letting you parameterize clients with different
  requests, queue or log requests, and support
  undoable operations.
• Also Known as
• Action, Transaction

3
Motivation(1)

• Sometimes its necessary to issue requests to
  objects without knowing anything about the
  operation being requested or the receiver of the
  request.
• Like impl. of buttons, menus in user interface
  toolkits.
• The Command pattern lets toolkit objects make
  requests of unspecified application objects by
  turning the request itself into an object.

4
Motivation(2)

• The key of this pattern is an abstract Command
  class, which declares an interface for executing
  operations.
• Concrete Command subclasses specify a
  receiver-action pair by storing the receiver as
  an instance variable and by implementing Execute
  to invoke the request.

5
Motivation(3)
Command -gtExecute()
Document
Open() Close() Cut() Copy() Paste()

• Application creates menus and menuitems.
• Application also keep track of Document objects.

6
Motivation(4)
Document
Open() Close() Cut() Copy() Paste()
document-gt Paste()

• PasteCommand supports pasting text from the
  clipboard into a Document

7
Motivation(5)
Application
Add(Document)
nameAskUser() doc new Document(name) doc-gtopen
()

• OpenCommand

8
Motivation(6)
for all c in commands c-gtExecute

• Macro Command to execute a series of commands

9
Motivation(7)

• The Command pattern decouples the object that
  invokes the operation from the one having the
  knowledge to perform it.
• We can replace commands dynamically.
• We can also support command scripting by
  composing commands into larger ones.

10
Applicability(1)

• Use this pattern when
• parameterize objects by an action to perform.
  Commands are object-oriented replacement for
  callbacks in procedural language.
• specify, queue, and execute requests at different
  time.
• support undo. The Commands Execute operation can
  store state for reversing its effects in the
  command itself.

11
Applicability(2)

• support logging changes so that they can be
  reapplied in case of a system crash.
• structure a system around high-level operations
  built on primitives operations.

12
Structure
Client
Invoker
Command
Execute()
Receiver
ConcreteCommand
Action()
Execute()
state
13
Participants(1)

• 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 on Receiver.

14
Participants(2)

• Client(Application)
• creates a ConcreteCommand object and sets its
  receiver.
• Invoker
• asks the command to carry out the request.
• Receiver
• knows how to perform the operations associated
  with carrying out a request. Any class may serve
  as a Receiver.

15
Collaborations(1)

• The client creates a ConcreteCommand object and
  specifies its receiver.
• An Invoker object stores the ConcreteCommand
  object.
• 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 Execute.
• The ConcreteCommand object invokes operations on
  its receiver to carry out the request.

16
Collaborations(2)
aClient
aCommand
anInvoker
aReceiver
new Command(aReceiver)
StoreCommand(aCommand)
Execute()
Action()

• sequence diagram

17
Consequence

• Command decouples the object that invokes the
  operation from the one that knows how to perform
  it.
• Commands are first-class objects. They can be
  manipulated and extended like any other object.
• You can assemble commands into a composite
  command. (MacroCommand).
• Its easy to add new Commands, because you dont
  have to change existing classes.

18
Implementation(1)

• How intelligent should a command be?
• One extreme merely defines a binding between a
  receiver and the actions that carry out the
  request.
• Another extreme it implements everything itself
  useful when
• want to define commands that are independent of
  existing receiver. no suitable receiver exists,
  or when a command knows its receiver implicitly.
• Somewhere between commands that have enough
  knowledge to find their receiver dynamically.

19
Implementation(2)

• Supporting undo and redo
• additional state needed, including
• The Receiver object.
• the arguments to the operation performed on the
  receiver,
• any original values in the receiver that can
  change as a result of handling the request.

20
Implementation(3)

• Supporting undo and redo(2)
• The application needs a history list of commands
  that have been executed.
• An undoable command might have to be copied
  before it can be placed on the history list.
• Commands that must be copied before being placed
  on the history list act as prototypes.

21
Implementation(4)

• Avoiding error accumulation in the undo process.
• Hysteresis can be a problem in ensuring a
  reliable, semantics-preserving undo/redo
  mechanism. Errors can accumulate.
• Memento pattern can be applied to give command
  access to this information without exposing the
  internals of other objects.

22
Implementation(5)

• Using C templates
• We can use templates to avoiding creating a
  Command subclass for every kind of action and
  receiver for commands that
• arent undoable
• dont require arguments
• Will be shown in the Sample Code section.

23
Sample Code(1)

• Abstract Command class
• class Command
• public
• virtual Command()
• virtual void Execute() 0
• protected
• Command()

24
Sample Code(2)

• OpenCommand class
• class OpenCommand public Command
• public
• OpenCommand(Application )
• virtual void Execute()
• protected
• virtual const char AskUser()
• private
• Application _application
• char _response
• OpenCommandOpenCommand(Application a)
• _application a

25
Sample Code(3)

• OpenCommand(continued)
• void OpenCommandExecute()
• const char name AskUser()
• if ( name ! 0)
• Document document new Document(name)
• _appplication-gtAdd(document)
• document-gtOpen()

26
Sample Code(4)

• PasteCommand class
• class PasteCommand public Command
• public
• PasteCommand(Document )
• virtual void Execute()
• private
• Document _document
• PasteCommandPasteCommand(Document doc)
• _document doc
• void PasteCommandExecute()
• _document -gt Paste()

27
Sample Code(5)

• template for simple command
• template ltclass Receivergt
• class SimpleCommand public Command
• public
• typedef void (ReceiverAction)()
• SimpleCommand(Receiver r, Action a)
• _receiver(r), _action(a)
• virtual void Execute()
• private
• Action _action
• Receiver _receiver

28
Sample Code(6)

• template for simple command
• template ltclass Receivergt
• void SimpleCommandltReceivergtExecute()
• (_receiver-gt_action)()

29
Sample Code(7)

• Using template
• MyClass receiver new MyClass
• command aCommand
• new SimpleCommandltMyClassgt
• (receiver, MyClassAction)
• aCommand-gtExecute()

30
Sample Code(8)

• MacroCommand class
• class MacroCommand public Command
• public
• MacroCommand()
• virtual MacroCommand()
• virtual void Add(Command )
• virtual void Remove(Command )
• virtual void Execute()
• private
• ListltCommand gt _cmds

31
Sample Code(9)

• Execute MacroCommand
• void MacroCommandExecute()
• LIstIteratorltCommandgt i(_cmds)
• for(i.First() !i.IsDone() i.Next())
• Command c i.CurrentItem()
• c-gtExecute()

32
Sample Code(10)

• void MacroCommandAdd(Command c)
• _cmds-gtAppend(c)
• void MacroCommandRemove(Command c)
• _cmds-gtRemove(c)

33
Related Patterns

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