设计模式 ☞ 行为型之命令模式
1.1 简介
1.1.1 概述
命令(Command)模式的定义如下：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。这样两者之间通过命令对象进行沟通，这样方便将命令对象进行储存、传递、调用、增加与管理。比如看电视时，我们只需要轻轻一按遥控器就能完成频道的切换，这就是命令模式，将换台请求和换台处理完全解耦了。电视机遥控器(命令发送者)通过按钮(具体命令)来遥控电视机(命令接收者)。
1.1.2 优缺点
优点： ① 通过引入中间件(抽象接口)降低系统的耦合度。 ② 扩展性良好，增加或删除命令非常方便。采用命令模式增加与删除命令不会影响其他类，且满足“开闭原则”。 ③ 可以实现宏命令。命令模式可以与组合模式结合，将多个命令装配成一个组合命令，即宏命令。 ④ 方便实现 Undo 和 Redo 操作。命令模式可以与后面介绍的备忘录模式结合，实现命令的撤销与恢复。 ⑤ 可以在现有命令的基础上，增加额外功能。比如日志记录，结合装饰器模式会更加灵活。
缺点： ① 可能产生大量具体的命令类。因为每一个具体操作都需要设计一个具体命令类，这会增加系统的复杂性。 ② 命令模式的结果其实就是接收方的执行结果，但是为了以命令的形式进行架构、解耦请求与实现，引入了额外类型结构(引入了请求方与抽象命令接口)，增加了理解上的困难。不过这也是设计模式的通病，抽象必然会额外增加类的数量，代码抽离肯定比代码聚合更加难理解。
1.2 案例
客户去饭店吃饭的时候，点蒸羊羔，蒸熊掌，蒸鹿尾儿，烧花鸭，烧雏鸡儿。服务员会一一记录在单子上，然后通知后厨开始制作，如果中途想要更改，服务员也会在单子上做相应的操作并通知后厨。我们不用管服务员是怎么干的，我们只管向服务员标明诉求，我们得到结果就行了。如下图所示，客户就是客户端(Client)，服务员就是发送者(Invoker)，单子就是命令(Command)，后厨就是接收者(Receiver)。
