在軟件系統中，“行為請求者”與“行為實現者”通常呈現一種“緊耦合”。但在某些場合，比如要對行為進行“記錄、撤銷/重做、事務”等處理，這種無法抵御變化的緊耦合是不合適的。在這種情況下，如何將“行為請求者”與“行為實現者”解耦？將一組行為抽象為對象，實現二者之間的松耦合。這就是命令模式（Command Pattern）。
在OOP中，一切都是對象，將請求封裝成對象，符合OOP的設計思想，當將客戶的單個請求封裝成對象以後，我們就可以對這個請求存儲更多的信息，使請求擁有更多的能力；命令模式同樣能夠把請求發送者和接收者解耦，使得命令發送者不用去關心請求將以何種方式被處理。
Command：
定義命令的接口，聲明執行的方法。
ConcreteCommand：
命令接口實現對象，是“虛”的實現；通常會持有接收者，並調用接收者的功能來完成命令要執行的操作。
Receiver：
接收者，真正執行命令的對象。任何類都可能成為一個接收者，只要它能夠實現命令要求實現的相應功能。
Invoker：
要求命令對象執行請求，通常會持有命令對象，可以持有很多的命令對象。這個是客戶端真正觸發命令並要求命令執行相應操作的地方，也就是說相當於使用命令對象的入口。
Client：
創建具體的命令對象，並且設置命令對象的接收者。注意這個不是我們常規意義上的客戶端，而是在組裝命令對象和接收者，或許，把這個Client稱為裝配者會更好理解，因為真正使用命令的客戶端是從Invoker來觸發執行。
1.命令模式的本質是對命令進行封裝，將發出命令的責任和執行命令的責任分割開。
2.每一個命令都是一個操作：請求的一方發出請求，要求執行一個操作；接收的一方收到請求，並執行操作。
3.命令模式允許請求的一方和接收的一方獨立開來，使得請求的一方不必知道接收請求的一方的接口，更不必知道請求是怎麼被接收，以及操作是否被執行、何時被執行，以及是怎麼被執行的。
4.命令模式使請求本身成為一個對象，這個對象和其他對象一樣可以被存儲和傳遞。
5.命令模式的關鍵在於引入了抽象命令接口，且發送者針對抽象命令接口編程，只有實現了抽象命令接口的具體命令才能與接收者相關聯。
class Receiver
{
public:
void Action()
{
cout<Action<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;
}
