序
前阵子在做一个东西时，用到了命令模式的变种，当时有些细节记不清了，于是去网上找了一些资料，结果越看越迷糊。最后索性自己重新推导了一次，在对推导过程作记录后，就有了这篇文章。
问题
使用word时，如果做错了某步操作，我们可以进行”撤销”,恢复到操作之前的状态。尽管每种操作都不一样，但是却神奇地能用同样的方式“撤销”。这是怎么做到的呢？
解决方案
从上面的描述，我们可以知道，word能做到这些功能:
- 以同样的方式表示所有可以撤销的操作
- 记录所有可以撤销的操作
由此，可以得到以下结构:
command_pattern_class1
仔细看看，好像有个问题: 命令的定义应该是通用的，如输入一段文字，但是我们撤消的是在某个地方输入的一段文字，所以还要加上命令执行的上下文，这里我们用Receiver来指代。更新后的类图:
command_pattern_class2
模式的理解
要理解命令模式，除了从它的应用场景推导之外，也可以从它的定义帮助理解:
命令一般应用于政府机构中。当某政府首脑发出命令时，一般不会由该首脑直接面对执行的人，而是通过类似国务院等机构发出。这里的国务院等机构就是命令模式里的Invoker，负责记录和执行。
命令里，一般会说清楚，要谁来做什么，所以，事实上命令(这里的命令不同于上面类图里的command)是由receiver和command两部分组成。
每过一段时间，都有人事上的一些变动，为第一次人事变动，都创建一种命令模板是不可能的，于是，政府对于主要的命令都规则了一个模板，每次需要的时间，只要把对应的人和职位变动内容填上去就可以了，这就是我们的command。
命令模式的类图
这部分网上的资料很多，我就不重复写了，以下内容摘自博客
command_pattern_diagra
适合场景与优缺点
命令模式有以下优点:
- 命令和实际的执行者分离，实际的操作都是通过invoker以及receiver去执行的
- 屏蔽了底层的复杂实现，对外提供了统一的表现
- 可以记录操作的历史记录
- 拓展性好，一方面，可以很方便地添加新的命令，如在word中添加插入html功能；另一方面，也可以把命令迁移到另一种场景下，如把word中的命令迁移到excel中
- 用户使用上，用户通过组合一些命令，可以实现宏的功能，效率更高
缺点:
- 代码冗余较多。每个命令，需要同时修改好几个地方，维护较复杂
由其优缺点，可以得出其适用场景:
- 编辑软件，如word,excel中，但是由于撤销依赖于当前状态，所以如果应用的状态无法完整保存，那么不应该提供撤销功能
- 由第一点，可以用于workflow、oa系统等软件中，用于定义流程、功能节点
- 由第三点，可以用于需要审计的系统中，用于审计
- shell中，用于对资源进行封装
- 第五点在很多文本编辑器中都有体现
不适用的场景:
- 功能足够简单。如果功能本身比较简单，则不建议引入命令模式，它会带来更多的复杂性，以及更高的开发成本
- 命令的意义不清晰或经常变化。命令模式在解耦命令的发出者与执行者的同时，也让命令发出者与执行者的联系不那么清晰，如果修改了命令的意义，要全面修改命令的调用者，会比较难
