什么是备忘录模式?备忘录的应用

2025-08-25 267944 日常编程

备忘录模式通过发起人、备忘录和负责人三者协作,实现对象状态的保存与恢复;发起人创建并恢复状态,备忘录存储状态且对外透明,负责人管理备忘录而不访问其内容,从而在不破坏封装性的前提下支持撤销、重做、游戏存档等场景。

备忘录模式,简单来说,就是一种在不破坏对象封装性的前提下,捕获并保存一个对象的内部状态,以便将来可以恢复到该状态的设计模式。它把对象的某个时刻的状态保存下来,就像拍了张快照。这听起来可能有点抽象,但想象一下你在玩游戏,随时可以存档、读档;或者在写文档,可以无限次地撤销、重做——这些功能背后,很可能就有备忘录模式的影子。它核心的价值在于,让我们能在需要的时候,把一个复杂对象“冻结”在某个特定状态,后续还能“解冻”回去,而这个过程对外部来说是透明的,不会暴露对象内部的实现细节。

备忘录模式的核心在于解耦:它将状态的保存和恢复逻辑从需要保存状态的对象(发起人 Originator)中分离出来,交给一个独立的备忘录对象(Memento)来承载。同时,还有一个负责人(Caretaker)来管理这些备忘录。

发起人(Originator)是那个拥有内部状态的对象,它知道如何创建自己的备忘录(即保存当前状态),也知道如何从备忘录中恢复状态。它就像一个艺术家,能够把自己的创作过程中的某个阶段“拍下来”,并能在需要时根据这张“照片”还原。

备忘录(Memento)则是一个纯粹的容器,用来存储发起人对象的内部状态。它通常对外提供一个窄接口,让负责人无法直接访问其内部细节,从而保护了发起人的封装性。对发起人而言,备忘录是透明的,可以访问其所有状态;但对负责人来说,备忘录就是个“黑盒子”,只能存储和传递,不能窥探。这种设计很巧妙,它确保了只有发起人自己能理解并操作自己的“快照”。

负责人(Caretaker)负责存储和管理备忘录对象。它从发起人那里获取备忘录,并在需要时将其还给发起人。负责人完全不知道备忘录内部到底存了些什么,它只管“存”和“取”,就像一个图书馆管理员,只负责图书的借阅和归还,而无需关心书本里的具体内容。

这种三角色协作的模式,完美地实现了状态保存与恢复的逻辑与业务逻辑的分离。我个人觉得,它最棒的地方就在于,它允许你在不污染原有业务逻辑代码的前提下,为对象增加“时间旅行”的能力。

备忘录模式解决的核心问题是什么?

我们为什么会需要备忘录模式?在我看来,它主要解决了一个非常实际且常见的痛点:如何在不打破对象封装性的前提下,保存并恢复其内部状态。设想一下,你有一个非常复杂的对象,比如一个图形编辑器中的画布对象,它包含了所有图层、图形、颜色、位置等信息。现在你需要实现“撤销”功能。

如果直接去访问画布对象的内部成员来保存状态,那无疑会打破它的封装性。一旦内部结构发生变化,所有依赖这些内部细节的保存/恢复代码都得跟着改,这简直是噩梦。而且,你可能需要保存很多个历史状态,手动管理这些状态的复杂性会迅速失控。

传统上,我们可能会想到深拷贝或者序列化。深拷贝固然能复制状态,但如果对象图很复杂,循环引用、资源管理等问题会让你头疼不已。序列化虽然可以将对象状态持久化,但它通常是为了跨进程或长期存储,对于内存中的频繁状态切换(比如撤销/重做)来说,性能开销可能过大,而且同样可能暴露内部结构。

备忘录模式的优雅之处在于,它把“如何保存状态”的细节封装在了发起人内部。发起人自己创建备忘录,自己从备忘录恢复。负责人只拿到一个“不透明”的备忘录对象,它不知道里面存了什么,也无法直接修改。这就像你把一个加密的盒子交给朋友保管,朋友只知道这是一个盒子,里面装了东西,但他打不开,只有你才能打开并取出里面的东西。这种设计完美地维护了对象的封装性,降低了耦合度。它让状态管理变得可控,而且对外部调用者来说,使用起来也极其简洁。

备忘录模式在实际开发中有哪些经典应用场景?

备忘录模式的应用场景其实非常广泛,只要涉及到“回溯”或“快照”功能的,它都是一个值得考虑的方案。

最经典的,无疑是撤销(Undo)和重做(Redo)功能。在任何文本编辑器、图形设计软件、CAD软件中,你进行的每一步操作都可以被撤销。每次操作完成后,软件可以创建一个当前状态的备忘录,并将其压入一个历史栈中。当用户点击“撤销”时,就从栈顶取出一个备忘录,恢复到上一个状态。这简直是备忘录模式的教科书式应用。

其次,游戏存档和进度保存也是备忘录模式的绝佳舞台。玩家在游戏中达到某个关键点,可以保存当前游戏状态,包括角色位置、物品、任务进度、敌人状态等等。这些复杂的内部状态被打包成一个或多个备忘录,然后可以序列化到文件或数据库中。下次玩家加载游戏时,就是从这些备忘录中恢复游戏世界。

在某些事务管理的场景中,备忘录模式也能发挥作用。比如,你可能需要执行一系列操作,但这些操作可能失败,或者需要提供回滚机制。你可以在操作开始前保存系统或关键对象的“快照”,如果操作失败,就利用备忘录恢复到初始状态。虽然数据库事务有其自身的机制,但在应用层处理某些业务逻辑的原子性时,备忘录提供了一种思路。

此外,在A/B测试或配置管理中,有时也需要保存和恢复不同的配置状态。比如,一个复杂的系统有多种运行配置,你可以在运行时切换到某个配置,然后又快速切换回另一个配置。每种配置都可以被视为一个备忘录。

如何实现一个简单的备忘录模式?

我们以一个简单的文本编辑器为例,看看如何用代码实现备忘录模式。这里用Python风格的伪代码来展示,因为它足够简洁明了。

# 1. 备忘录 (Memento)
class EditorMemento:
    def __init__(self, content):
        self._content = content

    def get_saved_content(self):
        return self._content

# 2. 发起人 (Originator) - 文本编辑器本身
class TextEditor:
    def __init__(self):
        self._content = ""

    def type(self, text):
        self._content += text
        print(f"当前内容: {self._content}")

    def save(self):
        # 创建一个备忘录,保存当前内容
        print("保存当前内容...")
        return EditorMemento(self._content)

    def restore(self, memento):
        # 从备忘录中恢复内容
        self._content = memento.get_saved_content()
        print(f"内容已恢复为: {self._content}")

# 3. 负责人 (Caretaker) - 历史管理器
class HistoryManager:
    def __init__(self):
        self._history = [] # 存储备忘录的列表

    def add_memento(self, memento):
        self._history.append(memento)
        print("备忘录已添加到历史记录。")

    def get_last_memento(self):
        if not self._history:
            return None
        # 取出并移除最后一个备忘录(模拟撤销)
        return self._history.pop()

# 客户端代码
if __name__ == "__main__":
    editor = TextEditor()
    history = HistoryManager()

    # 1. 初始状态
    editor.type("Hello, ")
    history.add_memento(editor.save()) # 保存状态1

    # 2. 修改状态
    editor.type("world!")
    history.add_memento(editor.save()) # 保存状态2

    # 3. 继续修改
    editor.type(" How are you?")

    # 4. 撤销一次
    print("\n执行撤销操作...")
    last_memento = history.get_last_memento()
    if last_memento:
        editor.restore(last_memento)
    else:
        print("没有可撤销的历史记录了。")

    # 5. 再撤销一次
    print("\n再次执行撤销操作...")
    last_memento = history.get_last_memento()
    if last_memento:
        editor.restore(last_memento)
    else:
        print("没有可撤销的历史记录了。")

    # 6. 尝试再次撤销(此时没有历史了)
    print("\n尝试再次撤销操作...")
    last_memento = history.get_last_memento()
    if last_memento:
        editor.restore(last_memento)
    else:
        print("没有可撤销的历史记录了。")

在这个例子中:

  • EditorMemento

    是备忘录,它简单地封装了文本内容。

  • TextEditor

    是发起人,它有

    _content

    状态,并提供了

    save()

    来创建备忘录,

    restore()

    来从备忘录恢复。

  • HistoryManager

    是负责人,它维护一个备忘录列表,负责添加和获取备忘录。它完全不关心备忘录内部是什么,只知道这是一个可以存储和取出的对象。

通过这种方式,

HistoryManager

可以管理

TextEditor

的多个历史状态,而无需知道

TextEditor

内部是如何存储文本的,完美地实现了封装和解耦。这就是备忘录模式的魅力所在。

以上就是什么是备忘录模式?备忘录的应用的详细内容,更多请关注就爱读【www.jiuaidu.com】。

为什么Python单例模式在多线程环境下会失效?

__new__中判空非原子操作会导致多线程重复创建实例;DCL通过无锁初判+加锁后复判解决,需配合__init__幂等防护。 __new__中的if判断不是原子操作 线程A执行到ifcls._instanceisNone时为True,刚准备调用super().__new__(cls),此时被调度挂起;线程B同样判空成功,也进入创建逻辑——结果两个线程各自生成实例并赋值给_instance。GIL不...

Python怎么配置Gunicorn_工作模式选择与Worker并发数量优化调优

是,--workers设多会导致CPU密集型任务上下文切换频繁;I/O密集型才适用多worker,建议从2或4起步压测调整,并注意preload引发的Flask上下文错误及worker-class是否真正生效。 gunicorn启动时CPU占用飙高、响应变慢,是不是--workers设多了? 不是“越多越好”,而是要匹配实际负载类型。CPU密集型任务(比如图像处理、数值计算)设太多--worker...

如何处理Python测试中大量的Mock对象维护_使用pytest-mock的Spy模式

spy比patch更适合监控已有逻辑,因为它不替换原函数,仅记录调用信息而不干预执行,避免行为脱节和副作用屏蔽;spy不可设return_value,应使用wraps实现监控+控制。 为什么spy比patch更适合监控已有逻辑 当你只是想确认某个函数被调用了、传了什么参数、返回了什么值,但又不想切断它的真实行为时,mocker.spy()是更轻量、更安全的选择。相比mocker.patch(),它...

如何实现在Python异步环境中进行分布式任务分发_结合Celery异步模式

Celery任务函数不能直接await,因其worker基于同步模型,不原生支持async/await;正确做法是用asyncio.to_thread()或线程池执行异步逻辑,或改用arq等原生异步任务队列。 在Python异步环境中直接用Celery处理异步任务,本质上是行不通的——Celery的worker是同步阻塞模型,不原生支持async/await。强行在task函数里写await会报R...

Python如何处理二进制文件的读写_通过open函数wb与rb模式

必须用rb/wb模式读写二进制文件,否则会触发文本编码/解码导致错误;rb返回bytes,wb要求写入bytes,不可混用文本方法如readline(),应使用read()或read(n)。 用open()读写二进制文件,必须显式指定rb和wb模式 Python默认以文本模式打开文件,哪怕你传入的是字节数据,也会触发编码/解码流程,导致UnicodeDecodeError或静默损坏数据。二进制文件...

如何实现Python中线程安全的单例模式_使用元类metaclass或Lock加锁

因为__new__不是原子操作:线程A判断_instance为None后,未执行super().__new__前,线程B也判为None,导致重复创建;GIL不保护跨语句逻辑,需用双重检查锁定(DCL)加threading.Lock确保线程安全。 为什么直接用__new__实现单例在多线程下会失效 因为__new__本身不是原子操作:线程A判断_instance为None后,还没来得及执行super...

Python处理JSON报JSONDecodeError怎么解决_利用try-except配合非严格模式解析

JSONDecodeError根本原因是输入文本违反RFC8259规范,常见触发场景包括BOM头、末尾逗号、单引号、注释、Unicode转义不全、换行符混用;Pythonjson模块无strict=False参数,严格解析不可绕过;推荐方案为预清洗后标准解析,次选ast.literal_eval(限可信Python字面量),或引入json5/demjson3第三方库;try-except需记录e....

如何解决Python测试中数据库连接频繁开闭问题_利用fixture的yield模式

pytestfixture中用yield管理pymysql连接更稳,因其确保无论测试是否异常都会执行清理;应避免全局连接池、多次close、共享连接,并在yield前ping保活和重置状态。 频繁在pytest测试中用pymysql.connect()打开又关闭数据库连接,不是“看起来不优雅”的问题,而是会直接拖慢测试执行、触发MySQL的max_connections限制、甚至让MySQLser...