如何让孩子爱上设计模式 ——17.命令模式(Command Pattern)

如何让孩子爱上设计模式 ——17.命令模式(Command Pattern)

标签： 设计模式初涉

---

描述性文字

本节讲解的是行为型设计模式种的：命令模式，该模式非常简单，
就是用于行为请求者与行为实现者的解耦，举个简单的例子，
摆地摊与开店的流程：(例子参考自大话设计模式)

摆地摊：
顾客 –点餐-> 老板 –收到点餐指令-> 制作菜肴
写成代码的话：就是顾客中持有对老板的引用，然后执行指令的时候
调用老板中制作菜肴的方法。这里的请求者直接与实现者进行交互，
耦合度比较高！

开店：

增加了一个服务员的角色，接收用户指令，处理指令，然后调用老板
进行菜肴制作，中途还可以记录命令请求，或者做撤销命令的操作。

先解析一波概念，然后再写一个简单的例子~

---

概念相关

模式定义：

将一个请求封装成一个对象，从而是你可用不同的请求对客户端参数化，
对请求排队或记录请求日志，以及支持可撤销的操作。

四个角色：

• Command：命令，声明具体命令的抽象接口。
• ConcreteCommand：具体命令，接收者对象绑定与一个动作。
• Receiver：接收者，执行与请求相关的操作，具体实现对请求的业务处理。
• Invoker：调用者，负责调用命令对象执行请求，相关的方法叫做行动方法。

UML类图：

适用场景

• 1.系统需要将请求调用者和请求接收者解耦，使得调用者和接收者不直接交互。请求
  调用者无须知道接收者的存在，也无须知道接收者是谁，接收者也无须关心何时被调用。
• 2.系统需要在不同的时间指定请求和执行请求。一个命令对象和请求的初始调用者可
  以有不同的生命期，换言之，最初的请求发出者可能已经不在了，而命令对象本身仍然
  是活动的，可以通过该命令对象去调用请求接收者，而无须关心请求调用者的存在性，
  可以通过请求日志文件等机制来具体实现。
• 3.系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作。
• 4.系统需要将一组操作组合在一起形成宏命令。

优缺点

优点：

• 1.更松散的耦合，请求者无需知道执行者是谁，如何执行指令。
• 2.更动态的控制，将请求封装，可以动态进行参数化，队列化，日志化等操作。
• 3.命令可以复合，即一个命令可以由多个命令组合而成，又叫宏命令。
• 4.更好的扩展性，因为命令发起者与执行者解耦，扩展新命令，只需实现新的
  命令对象，在需要的时候把具体的实现对象传入到命令对象中，就可以使用这个命令
  对象了，已有的实现完全不用变化。
• 5.为请求的撤销(Undo)和恢复(Redo)操作提供了一种设计和实现方案。

缺点：

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

---

代码示例

以前写过一个叫做宝宝电台的项目，里面播放控制部分，重构的时候就想着用
命令模式来实现相关控制，后来还是没时间写，这里用命令模式写个简单的播
放控制例子吧。

首先创建播放对象，就一个故事名和播放URL的属性

然后创建命令执行者，一个音乐播放器，提供设置播放列表，播放，暂停等方法

接着创建抽象命令接口，就一个execute()的方法

接着继承这个接口，写各种具体命令类，设置列表，播放，暂停，下一首，上一首
都是照葫芦画瓢，实现execute()方法，调用执行者里面的对应方法而已。

再接着是请求者类，低啊用命令对象执行具体的操作

最后客户端调用

输出结果

嘿嘿，命令模式就那么简单~

---

本节代码示例

https://github.com/coder-pig/DesignPatternsExample/tree/master/16.Command%20Pattern