命令模式是一个结构比较简单的设计模式，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模式。
