备忘录模式：对象状态快照与撤销重做的设计模式实践
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 状态保存的深水区：深拷贝与浅拷贝
这是实现备忘录模式时最容易出错的地方。当发起人的状态包含可变对象的引用（如List<String>,HashMap, 自定义对象等）时，简单的引用传递会带来灾难。
问题场景：假设Editor的状态中有一个List<String> paragraphs。
- 创建备忘录时，我们传递了
this.paragraphs的引用给备忘录。 - 用户后续修改了
editor.paragraphs（例如，增加了一段）。 - 此时，备忘录里保存的那个引用，指向的是同一个
List对象！所以备忘录中的“历史状态”也被意外修改了。撤销功能将失效。
解决方案：深拷贝在创建备忘录时，必须对可变状态进行深拷贝，即创建一个新对象，并递归复制其所有引用的对象。
import java.util.ArrayList; import java.util.List; public class Editor { private List<String> 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 List<String> paragraphs; private EditorMemento(List<String> paragraphs) { this.paragraphs = paragraphs; // 这里保存的是深拷贝后的List } private List<String> 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 Stack<Editor.EditorMemento> undoStack = new Stack<>(); private Stack<Editor.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()方法，来集中处理所有因状态恢复而需要执行的副作用操作。
备忘录模式就像给对象配备了一个精心设计的“备份与还原”系统。它通过清晰的职责划分，将状态管理的复杂性封装在几个特定的类中，让主业务逻辑保持简洁。在决定使用它之前，务必评估状态的大小、保存的频率以及内存的限制。在大多数需要撤销、历史或事务的场景中，它都是一个经得起考验的优雅解决方案。理解其深拷贝的核心要求，并警惕那些常见的实现陷阱，你就能在项目中游刃有余地驾驭这股“时光倒流”的力量。