设计模式-行为型-命令模式（COMMAND）

　　命令模式是一个结构比较简单的设计模式，gof在书中对它的定义是：“将一个请求封装为一个对象，从而使你可用不一样的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操做。”

　　这里有两个要点，第一请求被封装成了一个对象，第二请求能够被持久化（排队或是记录、取消）。

　　咱们从第一个要点提及。首先须要注意一点的全部COMMAND的模型均可以抽象出一个Execute概念或是相似概念。以下图（左）同样，这里的请求就是对文档作出paste操做，封装的结果就是经过PasteCommand的一个对象就能完成对一个特定document的操做，这个特定的document可能在构建这个PasteCommand对象时建立的，或者是在之后的使用中经过PasteCommand对象的成员变量设置的，不一而足，这全取决于你的实现。这样本来应该是一个函数作的事情变成了一个对象。乍一看仿佛这样的操做是画蛇添足，可是咱们回忆一下工厂模式里面提到的关于提出“工厂”这个抽象的好处，其中一个就是给程序带来了一个子类挂钩，这样能够将全部关于该请求的可能变化推迟到了command子类对象，一方面大大提升了程序的可读性也知足的开闭设计原则。下图（右）的例子就很好的说明了把请求封装成对象带给咱们的直接好处。

                        

　　接下来咱们看看，请求能够被持久化。第一点咱们看到因为新增了一个子类挂钩，给整个设计增长了很大的拓展性，全部的业务逻辑均可以封装到子类。同时由于新增了子类层次，子类对象也能够管理本身的状态，这种状态能够体如今调用对象，既是请求的记录上。由于有了子类层次，让这类信息的获取就直接转换成了经过子类对象的成员函数获取子类对象的状态这样的问题。

　　回顾一下上一个责任链模式的结构图。细心的读者会发现下图的蓝框里面的结构很像的命令模式，全部ConcreteHandler均可以被看做是一个COMMAND,全部的COMMAND共享一个概念HandleRequest，这个概念相似于Command的Execute。gof的书中提到了COMMAND于COMPOSITE的密切联系，CHAIN OF RESPONSIBILITY于COMPOSITE的密切联系。单单漏掉了CHAIN OF RESPONSIBILITY与COMMAND的联系，为何呢？ 就笔者的理解，CHAIN OF RESPONSIBILITY跟COMMAND，他们直接的关系就像是BUILDER与FACTORY METHOD同样，只有有形式上的联系。咱们能够注意到两个设计模式的定义，CHAIN OF RESPONSIBILITY强调了一样的请求被传递到不动的处理节点，可是COMMAND模式则是转换请求为一个对象，一个是请求传递，一个是请求转换。全部根本上两个模式的设计目的是不一样的。那么这个设计模式在现实当中有用处吗？笔者注意到C++11标准或是boost库中的thread类，将对执行流的要求转换成了对thread对象的调用，只是thread类没有实现请求持续化的要求，thread类有的是保存了执行流的状态。可是不妨碍它把请求转换成对象的事实，全部笔者认为thread类就是一个弱化的command模式。