一、概念

本質(zhì)是一種數(shù)據(jù)驅(qū)動、事件驅(qū)動的設(shè)計模式。

1.1、定義

又稱為動作(Action)模式或事務(wù)(Transaction)模式。將一個請求封裝為一個對象，從而使我們可用不同的請求對客戶進(jìn)行參數(shù)化；對請求排隊或者記錄請求日志，以及支持可撤銷的操作。

Command.png

• Receiver，接收者類：封裝命令的執(zhí)行過程
• Command，命令類抽象：對命令的封裝，其需要指定接收者Receiver
• Invoker，調(diào)用者類：封裝命令的實際調(diào)用者，執(zhí)行的時候需要指定具體的ConcreteCommand
• ConcreteCommand，具體命令類

1.2、解決的問題

• 問題分析：存在這樣一種場景，派發(fā)一個事件Event，執(zhí)行對應(yīng)的動作。即
• 模式的解決思路：將「命令Command」的「調(diào)用者Invoker」和「接收者Receiver」隔離解耦，命令、調(diào)用者、接收者彼此獨立變化。
  命令模式可以對發(fā)送者和接收者完全解耦，發(fā)送者與接收者之間沒有直接引用關(guān)系，發(fā)送請求的對象只需要知道如何發(fā)送請求，而不必知道如何完成請求。

二、模式的應(yīng)用和優(yōu)缺點

2.1、應(yīng)用場景

• 實例：
  struts 1 中的 action 核心控制器 ActionServlet 只有一個，相當(dāng)于 Invoker，而模型層的類會隨著不同的應(yīng)用有不同的模型類，相當(dāng)于具體的 Command。

2.2、優(yōu)缺點

• 優(yōu)點
  降低系統(tǒng)的耦合度
  新的命令可以很容易地加入到系統(tǒng)中
  可以比較容易地設(shè)計一個命令隊列和宏命令（組合命令）
  可以方便地實現(xiàn)對請求的Undo和Redo

• 缺點
  可能會導(dǎo)致某些系統(tǒng)有過多的具體命令類，增加系統(tǒng)的復(fù)雜性。