So, you have a command, but what if that command is a narrowing function, like a
modulo where multiple inputs map to the same output? You want to execute it but
are concerned it might not be the right action. In effect, you wish to be
reassured you can restore the object’s state at will, reverting any changes you
have made.
You may have tried to serialise the object’s state but found that serialisation
caused unwanted overhead. You may have wanted to do the reverse of the action
taken but found there was no way to reverse it, as exemplified by the modulo.
If this is the case, you need a way to store and restore the internal state.
The GoF book proposed the Memento pattern as a solution.
Before committing the action, request a Memento from the object, and only then make
the call or adjustment you wish to make. Usually, it’s created and stored by a
Command so it can return the object to its original state when you call the
Unexecute method. A Command can pass the Memento back to the object,
restoring its state.
Unfortunately, Memento was identified as something constructed from the
object of the action, not from the action itself. Therefore, it loses the
capacity to store only the minimal data necessary to return the object to its
prior state. The GoF book mentions keeping an incremental state, but this seems
post hoc, including changes brought about by previous actions, but not the
state changing due to the action about to be taken. To Unexecute a Command,
an object restoring from Memento must look at not just the current Memento
but all the possible restoration points in history. This is possible, but it
couples things from the wrong side of the event.