我所理解的设计模式——对象行为之命令（Comand）模式

前言

在GOF设计模式书中提及，Comand模式的意图是将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。

GOF中列举了该模式的四种适用性：
1. 在不同时刻指定、排列和执行请求；（有栗子）
2. 支持取消操作；（慢慢体会）
3. 支持修改日志；（慢慢体会）
4. 用构建在原语操作上的高层操作构造一个系统。（慢慢体会）

扯淡由此开始

由一个小程序说起，用过CTP API的应该知道，CTP交易系统服务端对API的查询频率有限制，就是每一秒最多只能查询一次，前言Comand模式适用性的第一种说的就是这种情况，跟该模式定义也相当吻合。由此，可以将API向服务器发送的每一个请求封装成一个个对象，然后放进队列中，一秒钟发送一个请求。客户端发送请求时，完全不用担心会超出CTP交易系统的限制，只需将请求放入队列。
## 举个栗子，伪代码##

class Command；
    + virtual execute() = 0;
Class CommandQryOrder； //查询委托
    + execute(){api->reqQryOrder();}
class CommandQryPosition； //查询持仓
    + execute(){api->reqQryPosition();}
class CommandManager;  //请求管理
    - mMsgQueue
    + addCommand(Command* c)
    + run(){
      while(1) Command* c = mMsgQueue.pop(); c->execute(); sleep(1s);//每秒发送一个命令
    }

在实际业务中调用时，只需要向CommandManager中添加命令即可。

结束扯淡

这是自己改版过的Command模式，只是借鉴了其中一点，按照GOF设计模式中所讲的，完整的命令模式参与者应该涉及Command、ConcreteCommand、Client、Invoker、Reciever。
仔细分解一下：
Command：声明操作接口
ConcreteCommand：绑定具体动作，栗子中CommandQryOrder、CommandQryPosition
Client：请求发起者，这个好理解
Invoker：这个类似CommandManager，存储命令对象，并且要求命令对象执行请求
Reciever：栗子中并没有很明确的体现，但是Client直接操作CommandManager，可以说CommandManager也是Reciver