如何采用命令模式实现“撤销/恢复”

前言：现在大部分优秀的编辑器都带有 "撤销/恢复"功能。这个功能就是相当于传说中的”后悔药“，方便大家随时切换到以前的某一个点。

为了寻找“后悔药”，我们也开始了该功能的探索之旅。本文主要考虑的方法是采用命令模式实现该功能的思路！

mweb

xcode

美图

一、设计模式的一些术语

1、设计模式定义

设计模式（Design Pattern）是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结。

使用设计模式的目的：为了代码可重用性、让代码更容易被他人理解、保证代码可靠性。 设计模式使代码编写真正工程化；设计模式是软件工程的基石脉络，如同大厦的结构一样。

设计模式对一类问题提供了相应的解决方案，所以使用上与问题场景紧密结合。

2、设计原则

单一职责原则

一个类只做一件事，引起它变化的原因只有一个。

尽量避免修改一个功能时，影响太多其他的东西，这个原则的划分细粒度是一个难点，只能通过工作经验的积累才能过更好的应用

开闭原则

即对扩展开放，对修改关闭

提供良好的可扩展性，维护性。比如：创建一个图形基类，再创建一个方形，圆形，如果要新增别的图形，只需要新增一个类就要，不影响其他现有的功能和代码

里氏代换原则

即子类可以代替父类的全部功能。反过来就不行

比如写了一个鸟类，有会飞的功能，再写一个鸵鸟，集成这个鸟类，会飞的功能，就违反了这个原则

依赖倒转原则

即高层代码不应该依赖于底层代码，而应该依赖于接口，即面向接口编程。

我们的pc电脑，在设计USB 模块的时候，应该是要遵循usb2.0,3.0的接口编程，而不是为具体的u 盘，或者厂家的u 盘做专门的设计

接口隔离原则

使用多个隔离的接口，比使用单个接口要好。

降低耦合，方便维护，避免，集成后，执行很多不用的方法

合成/聚合复用原则

尽量使用对象组合，而不是继承来达到复用的目的。

降低耦合性，调高灵活性，可复用性

迪米特法则

两个类之间不必彼此直接通信，那么这两个类不应该直接发生相互作用。

通过第三者来降低耦合度

设计模式就是实现了这些原则，从而达到了代码复用、增加可维护性的目的。

3、基本的设计模式

设计模式分为三种类型，共23种。

* 创建型模式：单例模式、抽象工厂模式、建造者模式、工厂模式、原型模式。

* 结构型模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。

* 行为型模式：模版方法模式、命令模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式（Interpreter模式）、状态模式、策略模式、职责链模式(责任链模式)、访问者模式。

二、命令模式

1、定义

将一个请求封装为一个对象(即我们创建的Command对象），从而使你可用不同的请求对客户进行参数化; 对请求排队或记录请求日志，以及支持可撤销的操作。

2、UML 图

命令模式由以下角色组成：

—— 命令角色（Command）：定义命令的接口，声明执行的方法。

——具体命令角色（Concrete Command）：实现命令接口，是“虚”的实现；通常会持有接收者，并调用接收者的功能来完成命令要执行的操作。

——接收者角色（Receiver）：负责具体实施和执行一个请求。任何类都可能成为一个接收者，只要它能够实现命令要求实现的相应功能。

—— 请求者（调用者）角色（Invoker）：负责调用命令对象执行请求。

—— 客户角色（Client）：创建一个具体命令对象并设定该命令对象的接收者。

3、基本代码

4、优缺点

优点：

降低系统的耦合度。由于请求者与接收者之间不存在直接引用，因此请求者与接收者之间实现完全解耦，相同的请求者可以对应不同的接收者，同样，相同的接收者也可以供不同的请求者使用，两者之间具有良好的独立性。

新的命令可以很容易地加入到系统中。由于增加新的具体命令类不会影响到其他类，因此增加新的具体命令类很容易，无须修改原有系统源代码，甚至客户类代码，满足“开闭原则”的要求。

可以比较容易地设计一个命令队列或宏命令（组合命令）。

为请求的撤销(Undo)和恢复(Redo)操作提供了一种设计和实现方案。

缺点：

使用命令模式可能会导致某些系统有过多的具体命令类。因为针对每一个对请求接收者的调用操作都需要设计一个具体命令类，因此在某些系统中可能需要提供大量的具体命令类，这将影响命令模式的使用。

适用场景

在以下情况下可以考虑使用命令模式：

系统需要将请求调用者和请求接收者解耦，使得调用者和接收者不直接交互。请求调用者无须知道接收者的存在，也无须知道接收者是谁，接收者也无须关心何时被调用。

系统需要在不同的时间指定请求、将请求排队和执行请求。一个命令对象和请求的初始调用者可以有不同的生命期，换言之，最初的请求发出者可能已经不在了，而命令对象本身仍然是活动的，可以通过该命令对象去调用请求接收者，而无须关心请求调用者的存在性，可以通过请求日志文件等机制来具体实现。

系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作。

系统需要将一组操作组合在一起形成宏命令。

5、Demo 人物移动

UML图

具体代码，详见DEMO

6、宏命令 DEMO

核心思路就使用了组合命令

通过上面的一些探讨，大家是否发现了一些问题。

如果我们要增加新的命令类，就会出现大量的命令类爆发

Demo中的接受者类，运用的数组存储，恢复和撤销的数据，是否有更加优化的方案

如果我们要记录的命令操作非常多，数据储存非常大，该如何解决？

敬请期待后续优化...

文/Mob开发者平台 资深IOS开发工程师 赵义