1、预习
在这里我直接引用书里的例子（散户烧烤摊VS固定烧烤店）来比喻：对于烧烤摊来说，每一个客户都是直接与老板打交道，老板需要记录每一个客户的需求以及变化；而在烧烤店里你只需要将单子递给服务员，并不需要见到烤肉的人。说白了就是‘行为请求者’与‘行为实现者’之间是紧耦合还是松耦合的问题。所以命令模式需要做的就是把行为请求者和行为实现者分割开来，进而达到松耦合目的。比如这里：如果一个小的烧烤摊人太多时，老板就会记不住那么多，总是会漏掉一些人；而烧烤店就不存在这个情况，因为是由服务员进行管理的，所以点餐和付款都能够有效保证。
2、定义
命令模式：将一个请求封装为一个对象，从而使你可以用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销操作。
具体来说主要包括以下几个方面：
- Command命令类：用来声明执行操作的接口；这个类依赖于操作的实施者，因为任何一个命令都是需要某一个人来实施的，即通过给构造函数传递参数达到建立依赖关系的目的；
- ConcretCommand类：具体的某一个命令，继承自命令基类；将一个接收者对象绑定于一个动作，调用接收者相应的执行操作，以实现这个命令的执行。
- Invoker类：收集命令，并要求命令执行这个请求。
- Receiver类：接收者，知道如何实施与执行一个与请求相关的操作；任何类都有可能作为接收者。
最后的执行顺序：由客户端建立命令类，并指定命令的接收者；由Invoker收集命令，然后通知命令的执行；整个过程中并没有具体的告诉一个命令怎么执行，因为这个过程被封装到了具体的命令中，由具体的命令来调用接收者的执行方法。
3、作用
命令模式有以下几个作用：
- 他能比较容易的设计一个命令队列
- 在需要的情况下，可以比较容易的将命令记入日志
- 允许接受请求的一方决定是否否决请求
- 可以比较容易的实现对请求的撤销和重做
- 由于加进新的命令不影响其他的类，因此增加新的具体命令类很容易；
※※最大的优点就是：命令模式把请求一个操作的对象与知道怎么执行一个操作的对象分隔开来了；我的理解就是使各自的职责更加明确，操作的执行者只管执行某个请求即可，而不需要知道这个请求是从哪里传递过来的，也使得二者之间的耦合度降低。
4、保留疑问
其实这个模式，我在看过书然后抄过例子之后还是不很明白；特别是后面所说的几个作用，读了之后觉得没有具体落地，因此无法深入理解。目前也只是把概念过一遍，知道例子一个大概的实现过程，后面等实际使用到这个模式时才能真正明白这些作用描述的具体含义！