前言
又到年底了，也静不下心来写代码了，大家都很浮躁；翻出经典的《仙剑奇侠传》玩一会；又要打大BOSS，先存一下档吧。这是我的习惯，在打大BOSS之前，都要先存一下档，要是打赢了，就再存一个档，覆盖之前的；如果打输了，就恢复之前的存档，接着重来。我想大家都是这么玩的吧。哎呀，总是打不过。好了，不玩了，但是，游戏中的那个存档行为却让我很着迷，它是如何实现的呢？带着好奇的心，去百度了一下；哦，原来如此。好吧，开始今天的总结吧——备忘录模式。
备忘录模式
在GOF的《设计模式:可复用面向对象软件的基础》一书中对备忘录模式是这样说的：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。
有时有必要记录一个对象的内部状态。为了允许用户取消不确定的操作或从错误中恢复过来，需要实现检查点和取消机制，而要实现这些机制，你必须事先将状态信息保存在某处，这样才能将对象恢复到它们先前的状态。如何实现这个将状态信息保存在某处呢？使用原型模式？由于对象通常封装了其部分或所有的状态信息，使得其状态不能被其他对象访问，也就不可能在该对象之外保存其状态了。由于原型模式总是返回对象的全部状态信息，同时原型模式使其状态能被其它对象访问，这样就违反了封装的原则，还可能有损应用的可靠性和可扩展性。
再拿上面的《仙剑奇侠传》进行分析，当我们在打大BOSS之前存档，此时就需要将对应的游戏场景，任务信息，人物信息等等状态存储起来；当赢得大BOSS之后，覆盖之前的存档时，就将之前的存档丢弃，新建立一个存档，保存当前的状态信息；如果打输了，恢复存档，就将之前的存档信息读取出来，还原到打大BOSS之前的游戏场景，重新开始打大BOSS。这里面就是使用的备忘录模式。
一个备忘录是一个对象，它存储另一个对象在某个瞬间的内部状态，而后者称为备忘录的原发器。当需要设置原发器的检查点时，取消操作机制会向原发器请求一个备忘录。原发器用描述当前状态的信息初始化该备忘录。只有原发器可以向备忘录中存取信息，备忘录对其他的对象是“不可见”的。
UML类图
Memento：备忘录存储原发器对象的内部状态。原发器根据需要决定备忘录存储原发器的哪些内部状态；防止原发器以外的其他对象访问备忘录。备忘录实际上有两个接口，管理者只能看到备忘录的窄接口————它只能将备忘录传递给其他对象。相反，原发器能够看到一个宽接口，允许它访问返回到先前状态所需的所有数据。理想的情况是只允许生成备忘录的那个原发器访问本备忘录的内部状态；
Originator：原发器创建一个备忘录，用以记录当前时刻它的内部状态；我们使用备忘录恢复内部状态；
Caretaker：负责保存好备忘录；但是，不能对备忘录的内容进行操作或检查。
备忘录模式是按照以下方式进行协作的：
管理器向原发器请求一个备忘录，保留一段时间后，将其送回给原发器；而有的时候管理者不会将备忘录返回给原发器，因为原发器可能根本不需要退到先前的状态。备忘录是被动的，只有创建备忘录的原发器会对它的状态进行赋值和检索，如下面的时序图：
使用场合
在以下情况下使用备忘录模式：
1.必须保存一个对象在某一个时刻的部分或完整状态，这样以后需要时它才能恢复到先前的状态；
2.如果一个用接口来让其它对象直接得到这些状态，将会暴露对象的实现细节并破坏对象的封装性。
代码实现：