备忘录模式如何实现对象状态回滚与撤销功能

在软件设计中实现撤销与恢复功能时，开发者通常会考虑全局历史记录或复杂的状态追踪。然而，备忘录模式（Memento Pattern）提供了一种更为优雅和封装性更强的解决方案。其核心理念可概括为“状态快照”与“隔离恢复”——即由对象自身负责其内部状态的备份与还原，而外部实体仅扮演快照保管者的角色，无权直接访问或修改状态内容。

发起人（Originator）：状态生命周期的唯一管理者

对象的状态是其核心私有数据，若允许外部直接访问，将彻底破坏封装原则。因此，发起人对象需对外提供两个关键方法：

• createMemento()：在状态发生变更前调用。此方法的核心在于执行深拷贝操作——无论是使用 Python 的 copy.deepcopy、Java 中创建全新对象实例，还是 Go 语言中显式复制切片与 map——以生成一份完全独立且只读的状态快照。
• restoreFromMemento(memento)：此方法职责单一，即从传入的备忘录对象中提取保存的状态值，并将其安全地赋值回自身的内部字段。整个过程不暴露字段细节，且确保外部无法修改备忘录内容。

备忘录（Memento）：实现真正不可变与封装的状态快照

备忘录并非简单的数据容器，而更像一个密封的保险箱，内部封装了特定时刻的完整对象状态：

• 字段完全私有化：在 Java 或 C# 中使用 private final 修饰；在 Go 中采用小写字母开头的未导出字段；在 Python 中则依赖约定与深拷贝机制共同保障。
• 提供受控的访问接口：通常仅向发起人暴露一个如 getSavedState() 的方法，且返回值应为不可变类型（如 String、ImmutableList）或其副本，以防止外部通过引用意外篡改快照数据。
• 严格限制构造权限：备忘录的构造函数应仅对发起人对象开放。这可通过 Java 的包访问权限、C++ 的 friend 声明或 Go 的同包可见性机制来实现，确保状态管理者无法私自创建或修改备忘录实例。

管理者（Caretaker）：专注存储中转，不涉及状态语义

管理者的角色极为纯粹，如同一个编号归档的仓库管理员：

• 使用栈、列表或数组等结构保存多个备忘录实例，以支持多步撤销与重做功能。
• 提供 push(memento)、pop() 或 get(index) 等基础存取方法。但必须注意，管理者绝不应调用备忘录的获取状态方法，也无需理解状态的具体含义。
• 其职责严格限定于存储与提供备忘录对象，不参与状态逻辑校验、快照合并或序列化等业务操作——所有与状态相关的业务逻辑都应封装在发起人对象内部。

状态回滚：确保粒度一致性与数据完整性

撤销操作的最大风险在于状态不一致。一次完整的回滚必须还原所有关联变量，避免部分状态遗漏：

• 例如，在文本编辑器中进行撤销时，若仅恢复了文本内容而忽略了光标位置与选中区域，将导致用户体验断裂。同样，在恢复游戏角色状态时，必须同时回滚生命值、魔法值、技能冷却时间等所有关联属性。
• 实用建议是：将逻辑上紧密关联的变量组合封装进同一个备忘录对象。例如 EditorMemento(content, cursorPosition, selectionRange)。
• 此外，若变量间存在计算依赖关系（如总价 = 单价 × 数量），应在发起人内部保存原始的、独立的字段值，而非存储计算后的衍生值。如此才能在恢复时确保基础逻辑的正确性与一致性。

总结而言，备忘录模式通过清晰的职责分离——发起人负责状态的生成与解析，备忘录负责封装不可变快照，管理者负责纯粹的存储管理——构建了一种既安全又灵活的状态回滚机制。该模式将状态变化的可能性封装在对象内部，同时对外提供简洁稳定的接口，充分体现了高内聚、低耦合的优秀软件设计原则。