在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。
一个备忘录（memento）是一个对象，它存储另一个对象在某个瞬间的内部状态，而后者称为备忘录的原发器。当需要设置原发器的检查点时，取消操作机制会向原发器请求一个备忘录。原发器用描述当前状态的信息初始化该备忘录。只有原发器可以向备忘录中存取信息，备忘录对其他的对象“不可见”。
必须保存一个对象在某一个时刻的（部分）状态，这样以后需要时它才能恢复到先前的状态。
如果一个用接口来让其他对象直接得到这些状态，将会暴露对象的实现细节并破坏对象的封装性。
备忘录存储原发器对象的内部状态。防止原发器以外的其他对象访问备忘录。理想的情况是指允许生成本备忘录的那个原发器访问本备忘录的内部状态。
管理器向原发器请求一个备忘录，保留一段时间后，将其送回给原发器。有时管理者不会将备忘录返回给原发器，因为原发器可能根本不需要退到先前的状态。备忘录是被动的。只有创建备忘录的原发器会对它的状态进行赋值和检索。
备忘录模式有以下一些效果：
1、保持封装边界。使用备忘录可以避免暴露一些只应有原发器管理却又必须存储在原发器之外的信息。该模式把可能很复杂的原发器内部信息对其他对象屏蔽起来，从而保持了封装边界。
2、它简化了原发器。在其他的保持封装性的设计中，原发器负责保持客户请求过的内部状态版本。这就把所有存储管理的重任交给了原发器。让客户管理它们请求的状态将会简化原发器，并且使得客户工作结束时无需通知原发器。
3、使用备忘录可能代价很高。如果原发器在生成备忘录时必须拷贝并存储大量的信息，或者客户非常频繁地创建备忘录和恢复原发器状态，可能会导致非常大的开销。除非封装和恢复原发器状态的开销不大，否则该模式可能并不适合。
4、管理器负责删除它所维护的备忘录。然而，管理器不知道备忘录中有多少个状态。因此当存储备忘录时，一个本来很小的管理器，可能会产生大量的存储开销。
备忘录有两个接口，一个为原发器所使用的宽接口，一个为其他对象所使用的窄接口。
如果备忘录的创建及其返回（给他们的原发器）的顺序是可预测的，备忘录可以仅存储原发器内部状态的增量改变。
一个包含可撤销的命令的历史列表可使用备忘录以保证当命令被取消时，它们可以被恢复到正确的状态。历史列表定义了一个特定的顺序，按照这个顺序命令可以被取消和重做。这意味着备忘录可以只存储一个命令所产生的增量改变而不是它所影响的每一个对象的完整状态。
Command模式：命令模式可使用备忘录来为可撤销的操作维护状态。
Iterator模式：备忘录可用于迭代。