备忘录模式：对象状态快照与撤销重做的设计模式实践

1. 项目概述从“后悔药”到状态快照在软件开发的日常里我们经常需要处理对象状态的保存与恢复。想象一个复杂的文本编辑器用户可能花了半小时调整格式、插入图片一不小心误操作或者想对比一下五分钟前的版本这时候一个“撤销”按钮就是救星。这个“撤销”功能背后的核心思想就是今天要拆解的备忘录模式。它不是什么高深莫测的黑科技而是一种优雅地解决“状态历史记录”问题的设计思路堪称面向对象编程里的“时光机”或“后悔药”。备忘录模式英文叫Memento Pattern属于行为型设计模式。它的核心职责非常简单在不破坏封装性的前提下捕获一个对象的内部状态并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原先保存的状态。听起来是不是和“备份”、“快照”的概念很像没错它的本质就是为对象创建状态快照。这个模式特别适合功能场景包括但不限于文本或图形编辑器的撤销/重做操作、游戏进度的存档与读档、事务回滚、浏览器历史记录等任何需要记录状态历史并可能回退的场景。对于开发者而言理解备忘录模式不仅能让你在需要实现撤销功能时思路清晰更能加深你对“封装”和“职责分离”这两个面向对象核心原则的理解。它巧妙地引入了一个“备忘录”角色来承载状态让原对象发起人和状态管理者负责人各司其职避免了状态管理逻辑污染业务核心类。接下来我们就深入这个模式的内部看看它是如何运作的以及在实际编码中如何避开那些常见的“坑”。2. 模式结构与核心角色解析备忘录模式的结构清晰通常涉及三个关键角色它们各司其职共同协作完成状态的保存与恢复。理解这三个角色之间的关系是掌握这个模式的关键。2.1 发起人 (Originator)发起人是拥有我们感兴趣的内部状态的那个对象。它负责创建备忘录用以记录当前时刻它的内部状态。同时它也负责使用备忘录来恢复自身的状态。你可以把它理解为需要被“存档”的那个实体比如文本编辑器里的文档对象、游戏里的玩家角色对象。发起人的核心职责有两项创建备忘录 (createMemento)生成一个当前对象状态的快照。这个快照通常是一个新的备忘录对象其内部包含了发起人当前所有需要保存的状态数据。恢复状态 (restoreMemento)接收一个备忘录对象并根据其中保存的数据将自己的状态恢复到备忘录所记录的那个历史时刻。这里有一个至关重要的设计原则发起人拥有对自身状态的完全访问权包括备忘录内部的私有状态。这通常通过在备忘录类中提供包级私有或友元在C中的访问方法来实现从而保证了状态的封装性不被外界除了发起人破坏。2.2 备忘录 (Memento)备忘录对象是一个“值对象”它的唯一使命就是存储发起人对象的内部状态。备忘录的设计是备忘录模式精妙之处它必须在两个看似矛盾的要求间取得平衡对发起人透明发起人需要能自由地向备忘录存入状态或从备忘录取出状态。对外界不透明除了发起人其他对象特别是负责人不应该、也不能够访问或修改备忘录内部的状态数据。这确保了状态信息的封装性和安全性防止历史记录被意外篡改。因此备忘录类通常具有以下特点其字段用来存储发起人的状态这些字段可以是基本类型也可以是对象的深拷贝取决于状态的可变性。它为发起人提供宽接口如getState(),setState()但这些方法对负责人和其他类是不可见的通过将方法设为包私有、或让备忘录作为发起人的内部类等方式实现。它对负责人只提供一个窄接口可能仅仅是一个标记接口没有任何方法或者只有一个获取元信息如时间戳的方法但绝不暴露实际状态。2.3 负责人 (Caretaker)负责人角色是备忘录的“保管员”。它负责保存备忘录但绝不能对备忘录的内容进行任何操作或检查。它只知道在某个时间点保存了一个备忘录并在需要的时候比如用户点击“撤销”将这个备忘录交还给发起人由发起人自己来执行恢复操作。负责人的职责非常单一保存一个或多个备忘录对象通常用栈、列表或字典等集合来管理以实现多次撤销或指定版本恢复。在适当的时机将保存的备忘录对象传递给发起人。这种职责分离的好处是显而易见的发起人专注于业务和状态管理负责人专注于历史记录的存储与调度备忘录则作为一个安全的数据载体。三者边界清晰耦合度低。三者关系流程图文字描述客户端如用户界面触发“保存状态”命令。客户端通知负责人。负责人向发起人请求一个备忘录originator.createMemento()。发起人创建并返回一个包含其当前状态的备忘录对象。负责人将这个备忘录对象存入其管理的历史记录集合中。当客户端触发“恢复状态”如撤销命令时负责人从集合中取出对应的备忘录。负责人将这个备忘录交还给发起人originator.restoreMemento(memento)。发起人使用备忘录中的数据将自己的状态恢复到历史点。3. 核心实现细节与代码演绎理解了角色我们通过一个经典的例子——文本编辑器的撤销功能——来具体实现一遍。我们会看到不同语言以Java为例如何实现状态保存的封装并深入探讨深拷贝与浅拷贝这个关键选择。3.1 场景定义简易文本编辑器假设我们有一个Editor类发起人它包含两个状态content文本内容和cursorPosition光标位置。我们需要支持多次撤销操作。3.2 备忘录的封装实现技巧如何让备忘录对发起人可读写对外部不可读这里有两种主流实现方式方式一使用内部类Java/C#等这是最优雅和安全的实现方式之一。将备忘录类定义为发起人Editor的私有静态内部类。这样只有Editor能直接构造和访问EditorMemento的细节。// 发起人 public class Editor { private String content; private int cursorPosition; // 创建备忘录 public EditorMemento createMemento() { // 注意这里传递的是String它是不可变对象。如果是可变对象需要考虑深拷贝。 return new EditorMemento(this.content, this.cursorPosition); } // 恢复状态 public void restoreMemento(EditorMemento memento) { // 因为EditorMemento是内部类Editor可以直接访问其私有字段 this.content memento.content; this.cursorPosition memento.cursorPosition; System.out.println(状态已恢复至: content (光标位置: cursorPosition )); } // 业务方法 public void type(String words) { this.content words; // 简化逻辑新输入后光标移到末尾 this.cursorPosition words.length(); } // 私有静态内部类备忘录 private static class EditorMemento { private final String content; // 使用final确保备忘录一旦创建不可变 private final int cursorPosition; private EditorMemento(String content, int cursorPosition) { this.content content; this.cursorPosition cursorPosition; } } }方式二使用包级私有访问权限Java或友元C如果备忘录和发起人不在同一个文件或类中可以通过控制访问权限来实现。在Java中可以将备忘录类放在同一个包内并将其构造函数和字段设为包级私有默认或无public修饰符这样只有同包下的发起人可以访问。// 文件 Editor.java package com.example.memento; public class Editor { private String content; public EditorMemento save() { return new EditorMemento(content); // 可以访问包私有的构造函数 } public void restore(EditorMemento m) { this.content m.getContent(); // 可以访问包私有的方法 } } // 文件 EditorMemento.java必须在同一个包 com.example.memento package com.example.memento; class EditorMemento { // 注意类不是public的 private final String state; // 包级私有的构造函数 EditorMemento(String state) { this.state state; } // 包级私有的getter仅对同包下的Editor可见 String getState() { return state; } }3.3 状态保存的深水区深拷贝与浅拷贝这是实现备忘录模式时最容易出错的地方。当发起人的状态包含可变对象的引用如ListString,HashMap, 自定义对象等时简单的引用传递会带来灾难。问题场景假设Editor的状态中有一个ListString paragraphs。创建备忘录时我们传递了this.paragraphs的引用给备忘录。用户后续修改了editor.paragraphs例如增加了一段。此时备忘录里保存的那个引用指向的是同一个List对象所以备忘录中的“历史状态”也被意外修改了。撤销功能将失效。解决方案深拷贝在创建备忘录时必须对可变状态进行深拷贝即创建一个新对象并递归复制其所有引用的对象。import java.util.ArrayList; import java.util.List; public class Editor { private ListString paragraphs new ArrayList(); public EditorMemento createMemento() { // 错误做法浅拷贝return new EditorMemento(this.paragraphs); // 正确做法深拷贝创建一个全新的ArrayList并复制所有元素。 // 注意这里假设List中的String元素是不可变的。如果元素本身是可变对象还需要对它们进行深拷贝。 return new EditorMemento(new ArrayList(this.paragraphs)); } public void restoreMemento(EditorMemento memento) { // 同样恢复时也应该用拷贝的数据避免后续修改影响备忘录。 this.paragraphs new ArrayList(memento.getSavedParagraphs()); } public void addParagraph(String text) { paragraphs.add(text); } // 备忘录内部类 private static class EditorMemento { private final ListString paragraphs; private EditorMemento(ListString paragraphs) { this.paragraphs paragraphs; // 这里保存的是深拷贝后的List } private ListString getSavedParagraphs() { // 返回一个副本进一步保护内部数据 return new ArrayList(paragraphs); } } }实操心得深拷贝的代价深拷贝保证了状态隔离但可能带来性能开销特别是当状态对象很大、嵌套很深时。在实际项目中需要权衡不可变对象是首选尽可能将需要保存的状态设计为不可变对象如String、Integer、自定义的不可变类。这样浅拷贝就是安全的性能最佳。序列化/反序列化对于复杂的对象图使用序列化如Java的Serializable到字节流再反序列化回来是一种通用的深拷贝方法但性能较低。拷贝工具库使用如Apache Commons Lang的SerializationUtils.clone()或JSON序列化/反序列化如Jackson, Gson来实现深拷贝。惰性恢复与差分存储对于极大型状态如整个文档模型完整保存每次快照内存消耗太大。可以考虑只保存增量修改命令模式与之结合或者仅在恢复时重新计算状态。3.4 负责人的实现与历史管理负责人History类通常使用栈Stack来支持“撤销”用另一个栈来支持“重做”。import java.util.Stack; public class History { private StackEditor.EditorMemento undoStack new Stack(); private StackEditor.EditorMemento redoStack new Stack(); public void save(Editor editor) { undoStack.push(editor.createMemento()); // 一旦有新的保存重做栈就应该清空因为新的操作分支了历史 redoStack.clear(); System.out.println(状态已保存。); } public void undo(Editor editor) { if (undoStack.isEmpty()) { System.out.println(无法撤销已无更早状态。); return; } Editor.EditorMemento memento undoStack.pop(); redoStack.push(editor.createMemento()); // 将当前状态先存入重做栈 editor.restoreMemento(memento); System.out.println(已执行撤销。); } public void redo(Editor editor) { if (redoStack.isEmpty()) { System.out.println(无法重做已无后续状态。); return; } Editor.EditorMemento memento redoStack.pop(); undoStack.push(editor.createMemento()); // 将当前状态存入撤销栈 editor.restoreMemento(memento); System.out.println(已执行重做。); } }客户端使用示例public class Client { public static void main(String[] args) { Editor editor new Editor(); History history new History(); editor.type(Hello World); history.save(editor); // 保存状态1: Hello World editor.type(Hello World, this is a new sentence.); history.save(editor); // 保存状态2: Hello World, this is a new sentence. System.out.println(当前内容: editor.getContent()); history.undo(editor); // 撤销到状态1 System.out.println(撤销后内容: editor.getContent()); history.redo(editor); // 重做到状态2 System.out.println(重做后内容: editor.getContent()); history.undo(editor); // 再次撤销到状态1 System.out.println(再次撤销后内容: editor.getContent()); } }4. 模式应用场景与变体实践备忘录模式的应用远不止撤销/重做。一旦你掌握了其“状态快照”的核心思想就能在很多需要记录和回溯状态的场景中发现它的用武之地。4.1 典型应用场景剖析游戏存档/读档这是备忘录模式的完美范例。游戏角色发起人的状态包括生命值、位置、装备、任务进度等。存档时创建这些状态的备忘录并序列化到磁盘文件。读档时从文件反序列化出备忘录并让角色恢复状态。负责人就是游戏系统的存档管理器。事务回滚在数据库或业务逻辑中一个复杂操作可能包含多个步骤。可以在每个步骤前创建业务对象状态的备忘录放入一个栈中。如果任何一步失败则依次弹出栈中的备忘录执行恢复操作将系统状态回滚到事务开始前。浏览器会话历史浏览器的前进、后退功能。每个页面的状态URL、DOM状态、滚动位置等可以被保存为一个备忘录。历史记录管理器负责人维护着这些备忘录的栈。配置管理软件的系统配置。用户可以修改一系列配置后通过“保存”创建当前配置的快照备忘录。如果想恢复出厂设置或之前的某个配置方案只需加载对应的备忘录即可。可视化编辑器除了文本图形编辑器中的图形位置、样式、图层关系等复杂状态同样可以通过备忘录模式来支持撤销操作。4.2 与其他模式的协作与变体备忘录模式很少孤立使用它常常与其他模式携手解决更复杂的问题。与命令模式结合这是实现强大撤销/重做系统的经典架构。命令模式封装了请求操作而备忘录模式可以保存命令执行前或执行后的接收者状态。具体有两种策略后状态备忘录命令执行后保存接收者的新状态到备忘录。撤销时用备忘录恢复状态。这种方式简单但可能消耗大量内存存储完整状态。前状态备忘录命令执行前保存接收者的原始状态到备忘录。撤销时用备忘录恢复状态。重做则需要重新执行命令。这种方式更节省内存但要求命令的执行是幂等的可重复执行且结果相同。与原型模式结合当发起人对象的状态非常复杂且创建深拷贝成本高昂时如果该对象支持原型模式克隆则创建备忘录可以简化为克隆当前对象。备忘录直接存储发起人对象的一个克隆体。恢复时用克隆体覆盖当前对象。这种方式将深拷贝的职责委托给了发起人自身的克隆机制。“增量备忘录”变体为了节省存储空间可以不保存完整状态而只保存上一次状态到当前状态的差异Delta。负责人保存的是一系列增量备忘录。恢复状态时需要从一个基准状态开始依次应用或回退这些增量。这类似于版本控制系统如Git的工作原理但对恢复逻辑的实现要求更高。“持久化备忘录”变体备忘录不仅可以保存在内存中还可以序列化后存储到数据库或文件系统中实现状态的持久化。这使得应用重启后仍能恢复状态常用于游戏存档、软件会话恢复等场景。5. 优势、劣势与实战避坑指南没有一种设计模式是银弹备忘录模式在提供优雅解耦的同时也带来了一些需要考虑的代价和陷阱。5.1 模式优势再审视封装性得以保全这是其最大的优点。发起人自身负责状态的保存与恢复外部对象负责人无法也无须知晓其内部状态结构符合面向对象设计的高内聚原则。简化发起人职责发起人不需要自己管理状态历史只需提供创建和恢复备忘录的接口。历史管理的复杂性被转移到了负责人那里。易于实现状态快照提供了一种标准化、可复用的状态快照机制使得实现撤销、历史、回滚等功能变得模式化代码结构清晰。5.2 潜在代价与挑战内存消耗如果发起人状态很大且需要保存大量历史快照例如支持无限次撤销则会消耗大量内存。这是最显著的代价。备忘录的寿命管理负责人持有备忘录的引用如果备忘录中包含了发起人状态的引用浅拷贝错误或大量数据可能会阻止垃圾回收器回收旧状态导致内存泄漏。深拷贝的实现复杂度与性能如前所述对于包含复杂对象图的状态实现正确且高效的深拷贝并非易事可能引入性能瓶颈。部分状态的暴露尽管通过窄接口做了限制但备忘录类本身的存在以及发起人对其内部方法的访问依然意味着这部分状态对发起人是“公开”的。在极端强调封装的场景下这可能被视为一种妥协。5.3 实战中的常见“坑”与规避策略坑1误用浅拷贝导致状态污染这是新手最容易犯的错误。保存了一个List或Map的引用后续操作却污染了历史记录。规避在createMemento()方法中对任何可变的状态成员执行深拷贝。使用不可变对象或不可变集合如Guava的ImmutableList是最佳实践。坑2负责人尝试操作备忘录内容违反了负责人“只保管不操作”的原则试图去读取或修改备忘录里的状态。规避严格定义角色边界。确保备忘录对负责人提供的接口是“只读”的或“无意义”的如仅一个getTimestamp()方法。在代码审查中重点关注负责人类看其是否调用了不该调的方法。坑3忽略备忘录的不可变性如果备忘录对象自身是可变的例如提供了setState方法那么其保存的状态就可能被任何能拿到该引用的人修改安全性荡然无存。规避将备忘录类设计为不可变类。所有字段用final修饰只提供获取状态的方法且返回深拷贝或不可变视图不提供任何修改方法。这在Java中可以通过将备忘录类设为final并私有化其构造函数来实现。坑4对庞大状态的全量保存对于一个包含整个文档DOM树或复杂图形场景的状态每次撤销都保存全量快照内存迅速告急。规避结合命令模式使用“前状态备忘录”或只保存反向命令逆操作而不是全量状态。差分存储只保存相邻两次状态之间的差异。懒加载/持久化将不常用的历史快照序列化到磁盘需要时再加载。设置历史深度上限只保留最近N次操作的历史超出部分丢弃。坑5状态恢复的副作用恢复状态时除了直接赋值字段可能还需要触发一些副作用比如更新UI、通知观察者、清理资源等。如果只在restoreMemento里简单赋值可能导致界面不同步或资源泄漏。规避将restoreMemento方法视为一个重要的状态变更事件。在方法内部先安全地更新内部状态然后调用一个私有的notifyStateChanged()或refresh()方法来集中处理所有因状态恢复而需要执行的副作用操作。备忘录模式就像给对象配备了一个精心设计的“备份与还原”系统。它通过清晰的职责划分将状态管理的复杂性封装在几个特定的类中让主业务逻辑保持简洁。在决定使用它之前务必评估状态的大小、保存的频率以及内存的限制。在大多数需要撤销、历史或事务的场景中它都是一个经得起考验的优雅解决方案。理解其深拷贝的核心要求并警惕那些常见的实现陷阱你就能在项目中游刃有余地驾驭这股“时光倒流”的力量。