标签： 设计模式初涉
描述性文字
本节讲解的是行为型设计模式种的：命令模式，该模式非常简单，
就是用于行为请求者与行为实现者的解耦，举个简单的例子，
摆地摊与开店的流程：(例子参考自大话设计模式)
摆地摊：
顾客 --点餐-> 老板 --收到点餐指令-> 制作菜肴
写成代码的话：就是顾客中持有对老板的引用，然后执行指令的时候
调用老板中制作菜肴的方法。这里的请求者直接与实现者进行交互，
耦合度比较高！
开店：
增加了一个服务员的角色，接收用户指令，处理指令，然后调用老板
进行菜肴制作，中途还可以记录命令请求，或者做撤销命令的操作。
先解析一波概念，然后再写一个简单的例子~
概念相关
模式定义：
将一个请求封装成一个对象，从而是你可用不同的请求对客户端参数化，
对请求排队或记录请求日志，以及支持可撤销的操作。
四个角色：
- 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
