c++++备忘录模式的核心组件包括发起人（originator）、备忘录（memento）和管理者（caretaker）。1. 发起人负责创建和恢复备忘录，保存其内部状态；2. 备忘录用于存储发起人的状态快照，对外提供窄接口、对发起人提供宽接口；3. 管理者负责保存和传递备忘录，不访问其内容。三者协同工作，在不破坏封装的前提下实现状态的保存与恢复，常用于实现撤销/重做功能。
C++的备忘录模式（Memento Pattern），本质上提供了一种机制，让你能在不破坏对象封装性的前提下，捕捉并外部化其内部状态，以便之后可以恢复到该状态。想象一下，就像你玩游戏时随时可以存档、读档，而游戏本身并不需要知道你究竟把存档文件放在了哪里，也不需要知道它内部的数据结构是怎样的。核心思想就是将对象状态的保存与恢复逻辑，从对象本身解耦出来。
备忘录模式通常包含三个核心角色：
在C++中实现时，一个常见的做法是让Originator内部定义一个Memento的嵌套类或者友元类，这样只有Originator才能访问Memento的私有成员，从而实现状态的封装。Caretaker则只持有Memento的指针或智能指针，通过一个公共的、不暴露内部细节的接口来操作它。
立即学习“C++免费学习笔记（深入）”；
谈到备忘录模式，我总会觉得它有点像一个高级的“时光机”——你把某个时刻的“世界”打包成一个盒子（备忘录），然后交给一个可靠的保管员（管理者）存起来。当你需要的时候，保管员把盒子还给你，你打开盒子，世界就回到了那个时间点。这三个角色，发起人、备忘录和管理者，缺一不可，各自扮演着独特而重要的职责。
发起人（Originator），它是那个“会变”的对象，它的状态是我们关注的焦点。比如，一个复杂的文本编辑器对象，它的状态可能包括当前文本内容、光标位置、选择区域等等。发起人需要提供两个核心方法：一个用于创建备忘录，将自己的当前状态打包进去；另一个用于接受一个备忘录，然后用里面的状态数据来恢复自己。这里面有个小技巧：为了保证封装性，发起人通常会是备忘录的“唯一知情者”，它知道备忘录里具体有哪些数据，也知道怎么把这些数据塞进去或取出来。
备忘录（Memento），它就是那个“状态的快照”。它仅仅是一个数据结构，用来存储发起人某一时刻的内部状态。它的设计哲学是“低调且私密”。对外，它可能只提供一个非常有限的接口（比如一个空的基类指针或者一个不暴露具体内容的句柄），让管理者能够存储和传递它，但不能窥探其内部。对内，它则允许发起人完全访问其私有数据。在C++里，这通常通过友元类、嵌套类或定义一个窄接口（给 Caretaker）和一个宽接口（给 Originator）来实现。我个人倾向于使用智能指针（如std::shared_ptr或std::unique_ptr）来管理备忘录的生命周期，避免手动内存管理带来的麻烦。
管理者（Caretaker），它是那个“保管员”。它的职责非常单纯：从发起人那里接收备忘录并保存起来，然后在需要的时候将备忘录还给发起人。管理者对备忘录的具体内容一无所知，它只知道备忘录是一个可以存储和传递的对象。这意味着管理者完全不依赖于发起人或备忘录的具体实现细节，它只与备忘录的抽象接口打交道。通常，管理者会用一个容器（比如std::vector<std::unique_ptr<Memento>>）来保存多个备忘录，以支持多级的撤销/重做操作。
这三者协同工作，使得发起人无需暴露其内部状态，而外部代码（管理者）也无需知道发起人的内部实现，就能够实现状态的保存和恢复。这在构建健壮、可维护的系统时，尤其是在需要实现撤销/重做功能时，显得尤为重要。
选择设计模式，从来都不是一道“非此即彼”的单选题，更多的是一种权衡和取舍。备忘录模式并非万能药，它有自己擅长的领域，也有其局限性。我通常在以下几种情况下会优先考虑它：
首先，当你的对象内部状态非常复杂，且你希望在不破坏其封装性的前提下，能够保存和恢复这些状态时，备忘录模式就显得非常合适。想想一个图形编辑器里的复杂图形对象，它可能包含了几十个属性，甚至嵌套了其他对象。如果你要实现撤销功能，直接暴露所有属性并手动保存，那简直是灾难。备忘录模式允许发起人自己决定哪些状态需要被保存，并以一种“黑盒”的方式提供给外部。这种对封装的尊重，是我个人非常欣赏的一点。
其次，当你需要实现多级撤销（Undo）和重做（Redo）功能时，备忘录模式几乎是首选。管理者可以简单地将一系列备忘录存储在一个列表中，每次撤销就是取出前一个备忘录，重做就是取出后一个。这种机制直观且易于扩展，比你自己手动管理所有历史状态要优雅得多。
再者，当对象的状态改变可能涉及事务性操作时，备备忘录模式也能派上用场。在某个操作开始前保存状态，如果操作失败，可以回滚到之前的状态。这有点像数据库的事务，要么全部成功，要么全部回滚。
然而，备忘录模式也有它的“缺点”。最明显的就是内存开销。如果你的对象状态非常庞大，每次保存一个备忘录都意味着复制一份完整的状态数据，这可能会迅速消耗大量内存。在这种情况下，你可能需要考虑“增量备忘录”或“差分备忘录”的优化，只保存状态的改变部分，而不是整个状态。但这样一来，模式的复杂度也会相应增加。
此外，如果你的对象状态非常简单，或者你并不介意直接暴露部分内部状态，那么备忘录模式可能会显得过于“重型”。在这种情况下，直接通过setter/getter方法来保存和恢复状态可能更简单直接。例如，一个只有几个基本类型成员的对象，为它专门设计一套备忘录模式，可能就有点杀鸡用牛刀了。
与命令模式（Command Pattern）相比，备忘录模式更侧重于状态的保存与恢复，而命令模式则侧重于将操作封装成对象。两者在实现撤销/重做时常被结合使用：命令对象在执行前保存状态（通过备忘录），执行后如果需要撤销，则恢复到之前的状态。它们是互补的，而非替代关系。
实现备忘录模式，虽然概念上直观，但在C++的实际编码中，确实有一些容易踩坑的地方，以及一些可以提升效率和代码质量的优化策略。
首先，深拷贝与浅拷贝是一个经典陷阱。如果你的发起人对象内部包含指针或动态分配的资源，那么在创建备忘录时，仅仅进行浅拷贝是远远不够的。浅拷贝只会复制指针本身，导致多个备忘录可能指向同一块内存，一旦其中一个备忘录或发起人修改了这块内存，其他备忘录的状态就会被意外改变，这显然不是我们想要的结果。正确的做法是执行深拷贝，确保备忘录内部存储的是独立于发起人状态的完整副本。这通常意味着你需要在备忘录的构造函数或复制方法中，手动或通过智能指针进行资源的复制。
其次，内存管理是另一个需要关注的点。备忘录对象通常由发起人创建，然后交给管理者存储。如果管理者持有的是原始指针，那么谁来负责释放这些备忘录的内存呢？这很容易导致内存泄漏。我强烈建议使用C++的智能指针，特别是std::unique_ptr或std::shared_ptr，来管理备忘录的生命周期。管理者可以存储std::unique_ptr<Memento>的集合，这样当备忘录不再需要时，内存会自动释放。如果多个发起人或管理者可能共享同一个备忘录（虽然在典型应用中不常见），那么std::shared_ptr会更合适。
再来，备忘录的接口设计。为了维护封装性，备忘录对外（给管理者）应该提供一个“窄接口”，不暴露其内部状态的细节。而对内（给发起人）则需要一个“宽接口”，让发起人能够完全访问和恢复状态。这可以通过将发起人声明为备忘录的friend类，或者在备忘录中定义一个私有结构体，并通过一个公共的、返回该结构体引用的方法（仅供发起人调用）来实现。我个人倾向于友元类，它直接了当，虽然有时会被认为打破了封装，但在这里，它正是为了在特定场景下维护更高级别的封装。
性能考量也是不可忽视的。如果你的对象状态非常庞大，或者撤销/重做操作非常频繁，每次创建完整备忘录的深拷贝开销可能会很大。这时可以考虑增量备忘录或差分备忘录的策略。即备忘录不存储完整的对象状态，而是只存储从上一个状态到当前状态的“变化量”。恢复时，则需要从初始状态开始，依次应用这些变化量。这会增加恢复的复杂性，但能显著减少内存占用和创建备忘录的时间。例如，在一个文本编辑器中，备忘录可以只记录“在某行某列插入了X字符”或“删除了Y字符”，而不是整个文档的内容。
最后，多线程环境下的同步问题。如果发起人对象的状态在多线程环境下被修改，并且你也需要在多线程中创建或恢复备忘录，那么你需要确保对发起人状态的访问是线程安全的，例如使用互斥锁（std::mutex）。否则，可能会在创建备忘录时捕捉到不一致的状态，或者在恢复时导致数据损坏。
这些陷阱和优化策略，都是在实际项目中摸爬滚打后总结出来的经验。模式本身是理论框架，而如何将其优雅、高效地落地到C++代码中，才是真正的挑战。
以上就是怎样应用C++的备忘录模式 对象状态保存与恢复机制的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
242
收藏
