The canonical strategy is to use the Team Template . You will represent what you can do as Command objects, and each object is pushed onto the stack. The state of the application is then determined by the initial state plus everything that the stack has. Thus, the undo operation then simply pops the top element of the stack and reapplies the remaining elements to the original state.
In practice, sometimes it is worth continuing to apply these operations to the initial state to generate the current state. For example, this might be true with something like a complex series of image settings, as you can find in Photoshop. In such cases, an alternating series of states is usually stored in memory:
+---------+ | state_0 | +---------+ +---------+ | next -------> | stack_0 | +---------+ +---------+ | data | +---------+ | next -------> | state_1 | +---------+ +---------+ | next ----- ... +---------+
Each stack_i contains instructions until it exceeds some predefined complexity (for example, instructions exceed the computational cost of X ) or a sequence number (for example, an X restriction or more instructions is kept on the stack). At this point, a new intermediate state object state_i+1 to encapsulate the state and a new empty stack stack_i+1 to store new commands.
Thus, you need to apply a small sequence of commands to the last state of the snapshot to get the current state. This happens by storing entire states, which may not be possible for very large applications, but you can choose a snapshot just to optimize the state.
source share