在软件系统中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。

但在某些场合，比方要对行为进行“记录、撤销/重做、事务”等处理。这样的无法抵御变化的紧耦合是不合适的。在这样的情况下。怎样将“行为请求者”与“行为实现者”解耦？将一组行为抽象为对象。实现二者之间的松耦合。这就是命令模式（Command Pattern）。

在OOP中，一切都是对象，将请求封装成对象，符合OOP的设计思想。当将客户的单个请求封装成对象以后，我们就行对这个请求存储很多其它的信息。使请求拥有很多其它的能力；命令模式相同可以把请求发送者和接收者解耦，使得命令发送者不用去关心请求将以何种方式被处理。

Command：
定义命令的接口，声明运行的方法。

ConcreteCommand：
命令接口实现对象。是“虚”的实现；一般会持有接收者，并调用接收者的功能来完毕命令要运行的操作。

Receiver：
接收者，真正运行命令的对象。不论什么类都可能成为一个接收者。仅仅要它可以实现命令要求实现的对应功能。
Invoker：
要求命令对象运行请求。一般会持有命令对象，能够持有非常多的命令对象。这个是client真正触发命令并要求命令运行对应操作的地方。也就是说相当于使用命令对象的入口。
Client：
创建详细的命令对象，而且设置命令对象的接收者。注意这个不是我们常规意义上的client。而是在组装命令对象和接收者，也许。把这个Client称为装配者会更好理解，由于真正使用命令的client是从Invoker来触发运行。

1.命令模式的本质是对命令进行封装。将发出命令的责任和运行命令的责任切割开。
2.每个命令都是一个操作：请求的一方发出请求，要求运行一个操作；接收的一方收到请求。并运行操作。
3.命令模式同意请求的一方和接收的一方独立开来，使得请求的一方不必知道接收请求的一方的接口。更不必知道请求是怎么被接收，以及操作是否被运行、何时被运行，以及是怎么被运行的。

4.命令模式使请求本身成为一个对象。这个对象和其它对象一样能够被存储和传递。
5.命令模式的关键在于引入了抽象命令接口。且发送者针对抽象命令接口编程，仅仅有实现了抽象命令接口的详细命令才干与接收者相关联。

class Receiver
{
public:void Action(){cout<<"Receiver->Action"<<endl;}
};class Command
{
public:virtual void Execute() = 0;
};class ConcreteCommand : public Command
{
public:ConcreteCommand(Receiver *pReceiver) : m_pReceiver(pReceiver){}void Execute(){m_pReceiver->Action();}
private:Receiver *m_pReceiver;
};class Invoker
{
public:Invoker(Command *pCommand) : m_pCommand(pCommand){}void Invoke(){m_pCommand->Execute();}
private:Command *m_pCommand;
};int main()
{Receiver *pReceiver = new Receiver();Command *pCommand = new ConcreteCommand(pReceiver);Invoker *pInvoker = new Invoker(pCommand);pInvoker->Invoke();SAFE_DELETE(pInvoker);SAFE_DELETE(pCommand);SAFE_DELETE(pReceiver);return 0;
}