Design Patterns : Elements of Reusable Object-Oriented Software

Command History 
The final step in supporting arbitrary-level undo and redo is todefine a 
command 
history
, or list of commands that havebeen executed (or unexecuted, if some 
commands have been undone).Conceptually, the command history looks like this: 

---

Design Patterns: Elements of Reusable Object-Oriented Software 
76 
Each circle represents a Command object. In this case the user hasissued four 
commands. The leftmost command was issued first, followedby the second-leftmost, 
and so on until the most recently issuedcommand, which is rightmost. The line 
marked "present" keeps trackof the most recently executed (and unexecuted) 
command. 
To undo the last command, we simply call Unexecute on the most recentcommand: 
After unexecuting the command, we move the "present" line onecommand to the left. 
If the user chooses undo again, the next-mostrecently issued command will be undone 
in the same way, and we're leftin the state depicted here: 
You can see that by simply repeating this procedure we get multiplelevels of undo. 
The number of levels is limited only by the length ofthe command history. 
To redo a command that's just been undone, we do the same thing inreverse. Commands 
to the right of the present line are commands thatmay be redone in the future. 
To redo the last undone command, we callExecute on the command to the right of 
the present line: 

---

Design Patterns: Elements of Reusable Object-Oriented Software 
77 
Then we advance the present line so that a subsequent redo will callredo 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. Thusthe user can effectively 
go back and forth in time as needed torecover from errors.