设计模式 ☞ 行为型之命令模式

你的名字 2023-01-03 04:16 119阅读 0赞

## 1.1 简介 ##

### 1.1.1 概述 ###

命令(Command)模式的定义如下：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。这样两者之间通过命令对象进行沟通，这样方便将命令对象进行储存、传递、调用、增加与管理。比如看电视时，我们只需要轻轻一按遥控器就能完成频道的切换，这就是命令模式，将换台请求和换台处理完全解耦了。电视机遥控器(命令发送者)通过按钮(具体命令)来遥控电视机(命令接收者)。

![在这里插入图片描述][20210107103918140.png_pic_center]

### 1.1.2 优缺点 ###

**优点：**  
 ① 通过引入中间件(抽象接口)降低系统的耦合度。  
 ② 扩展性良好，增加或删除命令非常方便。采用命令模式增加与删除命令不会影响其他类，且满足“开闭原则”。  
 ③ 可以实现宏命令。命令模式可以与组合模式结合，将多个命令装配成一个组合命令，即宏命令。  
 ④ 方便实现 Undo 和 Redo 操作。命令模式可以与后面介绍的备忘录模式结合，实现命令的撤销与恢复。  
 ⑤ 可以在现有命令的基础上，增加额外功能。比如日志记录，结合装饰器模式会更加灵活。

**缺点：**  
 ① 可能产生大量具体的命令类。因为每一个具体操作都需要设计一个具体命令类，这会增加系统的复杂性。  
 ② 命令模式的结果其实就是接收方的执行结果，但是为了以命令的形式进行架构、解耦请求与实现，引入了额外类型结构(引入了请求方与抽象命令接口)，增加了理解上的困难。不过这也是设计模式的通病，抽象必然会额外增加类的数量，代码抽离肯定比代码聚合更加难理解。

## 1.2 案例 ##

客户去饭店吃饭的时候，点蒸羊羔，蒸熊掌，蒸鹿尾儿，烧花鸭，烧雏鸡儿。服务员会一一记录在单子上，然后通知后厨开始制作，如果中途想要更改，服务员也会在单子上做相应的操作并通知后厨。我们不用管服务员是怎么干的，我们只管向服务员标明诉求，我们得到结果就行了。如下图所示，客户就是客户端(Client)，服务员就是发送者(Invoker)，单子就是命令(Command)，后厨就是接收者(Receiver)。

![在这里插入图片描述][20210107104752155.png_pic_center]

[20210107103918140.png_pic_center]: /images/20221119/b5d0db16bcbd4882bd2837b036cf105c.png
[20210107104752155.png_pic_center]: /images/20221119/021e79e775974150add99cf253faadc1.png