设计模式之备忘录模式

 模式定义：

      在不破坏封装的前提下，捕获一个对象内部状态，并在该对象之外保存这个状态，这样就可以将该对象回复到原先保存前的状态。

    模式解说：

      在程序运行过程中，某些对象的状态处在转换过程中，可能由于某种原因需要保存此时对象的状态，一边程序运行到某个特定阶段，需要回复到对象之前处于某个点事的状态。如果使用一些公有接口让其他对象来的到对象的状态，便会暴露对象的实现细节。

    结构图：

    

      备忘录角色：备忘录角色存储“备忘发起角色”的内部状态。“备忘发起角色”根据需要决定备忘录角色存储“备忘发起角色”的那些内部状态。为了防止“备忘发起角色”以外的其他对象访问备忘录。备忘录实际有两个接口，“备忘录管理者角色”只能看到备忘录提供的窄接口，对于备忘录角色中存放的属性是不可见的。“备忘录发起角色”则能够看到一个宽接口，能够得到自己放入备忘录角色中的属性。

      备忘发起角色：“备忘发起角色”创建一个备忘录，用以记录当前时刻它的内部状态。在需要时使用备忘录回复内部状态。

      备忘录管理者角色：负责保存好备忘录。不能对备忘录的内容进行操作或检查。

    优缺点：

      保持封装边界，使用备忘录可以避免暴露一些只应由原发器管理却又必须存储在原发器之外的信息。该模式把可能很复杂的Originator内部信息对其他对象屏蔽起来，从而保持了封装边界。

      它简化了原发器在其他的保持封装性的设计中，Originator负责保持客户请求过的内部状态版本。它就把所有存储管理的重任交给了Originator。让客户管理它们请求的状态将会简化Originator，并且使得客户工作结束时，无需通知原发器。

      使用备忘录可能代价很高，如果原发器在生成备忘录时必须拷贝并存储大量的信息，或者用户非常频繁地创建备忘录和恢复原发器状态，可能会导致非常大的开销，除非封装和回复Originator状态的开销不大，否则该模式可能并不合适。

      维护备忘录的潜在价值。管理器负责删除它所维护的备忘录。然而，管理器不知道备忘录中有多少个状态，因此当存储备忘录时，一个本来很小的管理器，可能会产生大量的存储开销。

    使用性：

      必须保存一个对象在某一时刻的状态，这样以后需要时它能恢复到先前的状态；如果一个用接口来让其他对象直接得到这些状态，将会暴露对象的实现细节并破坏对象的封装性。

版权声明：本文为博主原创文章，未经博主允许不得转载。