Of course, you can combine these two approaches and choose to handle part of the request in the ConcreteCommand and forward other parts.

Benefits and Drawbacks

The Command pattern offers flexibility in several ways:

Decoupling the source or trigger of the event from the object that has the knowledge to perform the task.

Sharing Command instances between several objects.

Allowing the replacement of Commands and/or Receivers at runtime.

Making Commands regular objects, thus allowing for all the normal properties.

Easy addition of new Commands; just write another implementation of the interface and add it to the application.

Pattern Variants

Pattern variants include the following:

Undo – The Command pattern lends itself to providing undo functions. When you extend the Command interface with an undo method, the burden of reversing the last command is placed on the implementing class.

To support an undo for only the last command, the application needs to keep a reference only to the last command. When the client does an undo, the application has to call the undo method of just the last command.

However, users might be dissatisfied with undoing only the last command. To support multi-level undo, the application must keep track of all the commands in a history list. This history list also simplifies the repetitive execution of the same command.

To be able to undo a command, the Command needs to install some damage control. The command needs to save all the information required to repair the changed object. This information includes, but is not limited to, the receiver and any arguments and old values. The receiver has to be changed so that the command can restore the original values.

Remember that you can use these Commands several times in different contexts. You might therefore need to copy the Command before placing it in the history list. You can do that by implementing the Prototype pattern (see “ Prototype ” on page 28).

Copying the Command helps prevent the errors that arise from repeatedly undoing and redoing several Commands. Going back and forth in the history list should be no problem, but if implemented incorrectly, any errors will add up. To prevent this, the command should store as much information as necessary to reverse the action. If some of the information is stored in the receiver, the Memento pattern (see “ Memento ” on page 88) would be most appropriate to store the state of the receiver. The receiver can provide that Memento object to the Command object as its previous state. When the command needs to be undone, the Command object hands the Memento object back to the receiver.

MacroCommand – A MacroCommand is a collection of other Commands. You can create MacroCommand s by using the Composite pattern. Figure 2.5 shows a class diagram for the undo and MacroCommand variant. (For more information, see “ Composite ” on page 157.)

Figure 2.5. Class diagram showing both the undo and MacroCommand variant

43