Command Pattern

Starting Point Analysis

Requirement in this phase

Command Pattern Overview

1. Intent

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

2. Structure

   

3. Participants

   • Command
     • declares an interface for executing an operation.
   • ConcreteCommand (PasteCommand, OpenCommand)
     • 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 (MenuItem)
     • asks the command to carry out the request.
   • Receiver (Document, Application)
     • knows how to perform the operations associated with carrying out a request. Any class may serve as a Receiver.

4. Collaborations

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

     The following diagram shows the interactions between these objects. It illustrates how Command decouples the invoker from the receiver (and the request it carries out).

     

Command History Overview

Conceptually, the command history looks like the following graph, each circle represents a command object.

To undo the last command, we simply call Unexecute on the most recent command:

After unexecuting the command, we move the "present" line one command to the left. If the user chooses undo again, the next-most recently issued command will be undone in the same way, and we're left in the state depicted here:

You can see that by simply repeating this procedure we get multiple levels of undo. The number of levels is limited only by the length of the command history.

To redo a command that's just been undone, we do the same thing in reverse. Commands to the right of the present line are commands that may be redone in the future. To redo the last undone command, we call Execute on the command to the right of the present line:

Then we advance the present line so that a subsequent redo will call redo on the following command in the future.

Of course, if the subsequent operation is not another redo but an undo, then the command to the left of the present line will be undone. Thus the user can effectively go back and forth in time as needed to recover from errors

UML Design in this phase

Steps in this phase

1. step 1: Implement the command pattern without undo and redo feature. In my implementation, I only wrap the 'set' command, which is the command for editing spreadsheet, as an SetCommand object since it relates to the undo or redo feature. We can also do it for all the commands that support it by TxtInterface object.
2. step 2: Add undo and redo method for Invoker class. Since the SetCommand object is undoable. we have to store the state for undoing the command prior to invoking execute. The state here refers to that of the spreadsheet. It is impossible to store the whole spreadsheet as a state since it will consume a lot of memory. We only need to store a cell's previous expression for undoing the command. The expression can be converted from a tree object as stated in step 2 of Observer, Interpreter and Iterator Patterns. Undoing the command can be done by simply assigning this expression as a new expression, which execute a new commands again. This is slightly different from the command pattern, but it is very simple. If we save the state for undoing a command, we may have to save all the changes due to a change of a cell's expression or value even if we don't save the whole state of the spreadsheet. This also tells us a pattern is not a panacea, we should adapt it to our project.

References