本系列所有文章来自李建忠老师的设计模式笔记，系列如下： 设计模式(一)面向对象设计原则 23种设计模式(二)组件协作之模板方法 23种设计模式(三)组件协作之策略模式 23种设计模式(四)组件协作之观察者模式 23种设计模式(五)单一职责之装饰模式 23种设计模式(六)单一职责之桥模式 23种设计模式(七)对象创建之工厂方法 23种设计模式(八)对象创建之抽象工厂 23种设计模式(九)对象创建之原型模式 23种设计模式(十)对象创建之构建器 23种设计模式(十一)对象性能之单件模式 23种设计模式(十二)对象性能之享元模式 23种设计模式(十三)接口隔离之门面模式 23种设计模式(十四)接口隔离之代理模式 23种设计模式(十五)接口隔离之适配器 23种设计模式(十六)接口隔离之中介者 23种设计模式(十七)状态变化之状态模式 23种设计模式(十八)状态变化之备忘录 23种设计模式(十九)数据结构之组合模式 23种设计模式(二十)数据结构之迭代器 23种设计模式(二十一)数据结构之职责链 23种设计模式(二十二)行为变化之命令模式 23种设计模式(二十三)行为变化之访问器 23种设计模式(二十四)领域规则之解析器
在组件的构建过程中，组件行为的变化经常导致组件本身剧烈的变化。”行为变化“模式将组件的行为和组件本身进行解耦，从而支持组件行为的变化，实现两者之间的松耦合。
在软件构建过程中”行为请求者“与”行为实现责“通常呈现一种”紧耦合“。但在某些场合–比如需要对行为进行”记录“、撤销/重(undo/redo)、事务等处理，这种无法抵御变化的紧耦合是不合适的。
在这种情况下，如何将”行为请求者“与”行为实现者“解耦？将一组行为抽象为对对象，可以实现二者之间的松耦合。
将一个请求(行为)封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。
#include <iostream> #include <vector> #include <string> using namespace std; class Command { public: virtual void execute() = 0; }; class ConcreteCommand1 : public Command { string arg; public: ConcreteCommand1(const string & a) : arg(a) {} void execute() override { cout<< "#1 process..."<<arg<<endl; } }; class ConcreteCommand2 : public Command { string arg; public: ConcreteCommand2(const string & a) : arg(a) {} void execute() override { cout<< "#2 process..."<<arg<<endl; } }; class MacroCommand : public Command { vector<Command*> commands; public: void addCommand(Command *c) { commands.push_back(c); } void execute() override { for (auto &c : commands) { c->execute(); } } }; int main() { ConcreteCommand1 command1(receiver, "Arg ###"); ConcreteCommand2 command2(receiver, "Arg $$$"); MacroCommand macro; macro.addCommand(&command1); macro.addCommand(&command2); macro.execute(); }Command模式的根本目的在于将“行为请求者”与“行为实现者”解耦,在面向对象语言中，常见的实现手段是“将行为抽象为对象”。
实现Command接口的具体命令对象ConcreteCommand有时候根据需要可能会保存一 些额外的状态信息。通过使用Composite模式，可以将多个”命令”封装为一个“复合命令”MacroCommand。
Command模式与C+ +中的函数对象有些类似。但两者定义行为接口的规范有所区别: Command以面向对象中的 "接口-实现”来定义行为接口规范，更严格,但有性能损失; C+ +函数对象以函数签名来定义行为接口规范,更灵活,性能更高。
