——.NET設計模式系列之十七
TerryLee
，2006年7月
概述
在軟件系統(tǒng)中，“行為請求者”與“行為實現(xiàn)者”通常呈現(xiàn)一種“緊耦合”。但在某些場合，比如要對行為進行“記錄、撤銷/重做、事務”等處理，這種無法抵御變化的緊耦合是不合適的。在這種情況下，如何將“行為請求者”與“行為實現(xiàn)者”解耦？將一組行為抽象為對象，可以實現(xiàn)二者之間的松耦合[李建忠]。這就是本文要說的Command模式。
意圖
將一個請求封裝為一個對象，從而使你可用不同的請求對客戶進行參數(shù)化；對請求排隊或記錄請求日志，以及支持可撤消的操作。[GOF 《設計模式》]
結(jié)構(gòu)圖
Command
模式結(jié)構(gòu)圖如下：
圖1 Command模式結(jié)構(gòu)圖
生活中的例子
Command
模式將一個請求封裝為一個對象，從而使你可以使用不同的請求對客戶進行參數(shù)化。用餐時的賬單是Command模式的一個例子。服務員接受顧客的點單，把它記在賬單上封裝。這個點單被排隊等待烹飪。注意這里的"賬單"是不依賴于菜單的，它可以被不同的顧客使用，因此它可以添入不同的點單項目。
圖2 使用用餐例子的Command模式對象圖
Command
模式解說
在眾多的設計模式中，Command模式是很簡單也很優(yōu)雅的一種設計模式。Command模式它封裝的是命令，把命令發(fā)出者的責任和命令執(zhí)行者的責任分開。我們知道，一個類是一組操作和相應的一些變量的集合，現(xiàn)在有這樣一個類
Document
，如下：
圖3
示意性代碼：
///
<summary>
///
文檔類
///
</summary>
public
class
Document
{
///
<summary>
///
顯示操作
///
</summary>
public
void
Display()
{
Console.WriteLine(
"
Display
"
);
}
///
<summary>
///
撤銷操作
///
</summary>
public
void
Undo()
{
Console.WriteLine(
"
Undo
"
);
}
///
<summary>
///
恢復操作
///
</summary>
public
void
Redo()
{
Console.WriteLine(
"
Redo
"
);
}
}
一般情況下我們使用這個類的時候，都會這樣去寫：
Display()
，Undo()，Redo()這三個方法都應該是Document所具有的，如果單獨抽象出來成一個命令對象，那就是把函數(shù)層面的功能提到了類的層面，有點功能分解的味道，我覺得這正是Command模式解決這類問題的優(yōu)雅之處，先對命令對象進行抽象：
class
Program
{
static
void
Main(
string
[]args)
{
Documentdoc
=
new
Document();
doc.Display();
doc.Undo();
doc.Redo();
}
}
這樣的使用本來是沒有任何問題的，但是我們看到在這個特定的應用中，出現(xiàn)了Undo/Redo的操作，這時如果行為的請求者和行為的實現(xiàn)者之間還是呈現(xiàn)這樣一種緊耦合，就不太合適了。可以看到，客戶程序是依賴于具體Document的命令（方法）的，引入Command模式，需要對Document中的三個命令進行抽象，這是Command模式最有意思的地方，因為在我們看來
圖4
示意性代碼：
///
<summary>
///
抽象命令
///
</summary>
public
abstract
class
DocumentCommand
{
Document_document;
public
DocumentCommand(Documentdoc)
{
this
._document
=
doc;
}
///
<summary>
///
執(zhí)行
///
</summary>
public
abstract
void
Execute();
}
其他的具體命令類都繼承于該抽象類，如下：
圖5
示意性代碼：
///
<summary>
///
顯示命令
///
</summary>
public
class
DisplayCommand:DocumentCommand
{
public
DisplayCommand(Documentdoc)
:
base
(doc)
{
}
public
override
void
Execute()
{
_document.Display();
}
}
///
<summary>
///
撤銷命令
///
</summary>
public
class
UndoCommand:DocumentCommand
{
public
UndoCommand(Documentdoc)
:
base
(doc)
{
}
public
override
void
Execute()
{
_document.Undo();
}
}
///
<summary>
///
重做命令
///
</summary>
public
class
RedoCommand:DocumentCommand
{
public
RedoCommand(Documentdoc)
:
base
(doc)
{
}
public
override
void
Execute()
{
_document.Redo();
}
}
現(xiàn)在還需要一個Invoker角色的類，這其實相當于一個中間角色，前面我曾經(jīng)說過，使用這樣的一個中間層也是我們經(jīng)常使用的手法，即把A對B的依賴轉(zhuǎn)換為A對C的依賴。如下：
圖6
示意性代碼：
///
<summary>
///
Invoker角色
///
</summary>
public
class
DocumentInvoker
{
DocumentCommand_discmd;
DocumentCommand_undcmd;
DocumentCommand_redcmd;
public
DocumentInvoker(DocumentCommanddiscmd,DocumentCommandundcmd,DocumentCommandredcmd)
{
this
._discmd
=
discmd;
this
._undcmd
=
undcmd;
this
._redcmd
=
redcmd;
}
public
void
Display()
{
_discmd.Execute();
}
public
void
Undo()
{
_undcmd.Execute();
}
public
void
Redo()
{
_redcmd.Execute();
}
}
現(xiàn)在再來看客戶程序的調(diào)用代碼：
class
Program
{
static
void
Main(
string
[]args)
{
Documentdoc
=
new
Document();
DocumentCommanddiscmd
=
new
DisplayCommand(doc);
DocumentCommandundcmd
=
new
UndoCommand(doc);
DocumentCommandredcmd
=
new
RedoCommand(doc);
DocumentInvokerinvoker
=
new
DocumentInvoker(discmd,undcmd,redcmd);
invoker.Display();
invoker.Undo();
invoker.Redo();
}
}
可以看到：
1
．在客戶程序中，不再依賴于Document的Display()，Undo()，Redo()命令，通過Command對這些命令進行了封裝，使用它的一個關(guān)鍵就是抽象的Command類，它定義了一個操作的接口。同時我們也可以看到，本來這三個命令僅僅是三個方法而已，但是通過Command模式卻把它們提到了類的層面，這其實是違背了面向?qū)ο蟮脑瓌t，但它卻優(yōu)雅的解決了分離命令的請求者和命令的執(zhí)行者的問題，在使用Command模式的時候，一定要判斷好使用它的時機。
2
．上面的Undo/Redo只是簡單示意性的實現(xiàn)，如果要實現(xiàn)這樣的效果，需要對命令對象設置一個狀態(tài)，由命令對象可以把狀態(tài)存儲起來。
.NET
中的Command模式
在ASP.NET的MVC模式中，有一種叫Front Controller的模式，它分為Handler和Command樹兩個部分，Handler處理所有公共的邏輯，接收HTTP Post或Get請求以及相關(guān)的參數(shù)并根據(jù)輸入的參數(shù)選擇正確的命令對象，然后將控制權(quán)傳遞到Command對象，由其完成后面的操作，這里面其實就是用到了Command模式。
圖7Front Controller 的處理程序部分結(jié)構(gòu)圖
圖8 Front Controller的命令部分結(jié)構(gòu)圖
Handler
類負責處理各個 Web 請求，并將確定正確的 Command 對象這一職責委派給 CommandFactory 類。當 CommandFactory 返回 Command 對象后，Handler 將調(diào)用 Command 上的 Execute 方法來執(zhí)行請求。具體的實現(xiàn)如下
Handler
類：
接口：
類：
類：
類：
類：
效果及實現(xiàn)要點
///
<summary>
///
Handler類
///
</summary>
public
class
Handler:IHttpHandler
{
public
void
ProcessRequest(HttpContextcontext)
{
Commandcommand
=
CommandFactory.Make(context.Request.Params);
command.Execute(context);
}
public
bool
IsReusable
{
get
{
return
true
;
}
}
}
Command
///
<summary>
///
Command
///
</summary>
public
interface
Command
{
void
Execute(HttpContextcontext);
}
CommandFactory
///
<summary>
///
CommandFactory
///
</summary>
public
class
CommandFactory
{
public
static
CommandMake(NameValueCollectionparms)
{
string
requestParm
=
parms[
"
requestParm
"
];
Commandcommand
=
null
;
//
根據(jù)輸入?yún)?shù)得到不同的Command對象
switch
(requestParm)
{
case
"
1
"
:
command
=
new
FirstPortal();
break
;
case
"
2
"
:
command
=
new
SecondPortal();
break
;
default
:
command
=
new
FirstPortal();
break
;
}
return
command;
}
}
RedirectCommand
public
abstract
class
RedirectCommand:Command
{
//
獲得Web.Config中定義的key和url鍵值對，UrlMap類詳見下載包中的代碼
private
UrlMapmap
=
UrlMap.SoleInstance;
protected
abstract
void
OnExecute(HttpContextcontext);
public
void
Execute(HttpContextcontext)
{
OnExecute(context);
//
根據(jù)key和url鍵值對提交到具體處理的頁面
string
url
=
String.Format(
"
{0}?{1}
"
,map.Map[context.Request.Url.AbsolutePath],context.Request.Url.Query);
context.Server.Transfer(url);
}
}
FirstPortal
public
class
FirstPortal:RedirectCommand
{
protected
override
void
OnExecute(HttpContextcontext)
{
//
在輸入?yún)?shù)中加入項portalId以便頁面處理
context.Items[
"
portalId
"
]
=
"
1
"
;
}
}
SecondPortal
public
class
SecondPortal:RedirectCommand
{
protected
override
void
OnExecute(HttpContextcontext)
{
context.Items[
"
portalId
"
]
=
"
2
"
;
}
}
1
．Command模式的根本目的在于將“行為請求者”與“行為實現(xiàn)者”解耦，在面向?qū)ο笳Z言中，常見的實現(xiàn)手段是“將行為抽象為對象”。
2
．實現(xiàn)Command接口的具體命令對象ConcreteCommand有時候根據(jù)需要可能會保存一些額外的狀態(tài)信息。
3
．通過使用Compmosite模式，可以將多個命令封裝為一個“復合命令”MacroCommand。
4
．Command模式與C#中的Delegate有些類似。但兩者定義行為接口的規(guī)范有所區(qū)別：Command以面向?qū)ο笾械摹敖涌?實現(xiàn)”來定義行為接口規(guī)范，更嚴格，更符合抽象原則；Delegate以函數(shù)簽名來定義行為接口規(guī)范，更靈活，但抽象能力比較弱。
5
．使用命令模式會導致某些系統(tǒng)有過多的具體命令類。某些系統(tǒng)可能需要幾十個，幾百個甚至幾千個具體命令類，這會使命令模式在這樣的系統(tǒng)里變得不實際。
適用性
在下面的情況下應當考慮使用命令模式：
1
．使用命令模式作為"CallBack"在面向?qū)ο笙到y(tǒng)中的替代。"CallBack"講的便是先將一個函數(shù)登記上，然后在以后調(diào)用此函數(shù)。
2
．需要在不同的時間指定請求、將請求排隊。一個命令對象和原先的請求發(fā)出者可以有不同的生命期。換言之，原先的請求發(fā)出者可能已經(jīng)不在了，而命令對象本身仍然是活動的。這時命令的接收者可以是在本地，也可以在網(wǎng)絡的另外一個地址。命令對象可以在串形化之后傳送到另外一臺機器上去。
3
．系統(tǒng)需要支持命令的撤消(undo)。命令對象可以把狀態(tài)存儲起來，等到客戶端需要撤銷命令所產(chǎn)生的效果時，可以調(diào)用undo()方法，把命令所產(chǎn)生的效果撤銷掉。命令對象還可以提供redo()方法，以供客戶端在需要時，再重新實施命令效果。
4
．如果一個系統(tǒng)要將系統(tǒng)中所有的數(shù)據(jù)更新到日志里，以便在系統(tǒng)崩潰時，可以根據(jù)日志里讀回所有的數(shù)據(jù)更新命令，重新調(diào)用Execute()方法一條一條執(zhí)行這些命令，從而恢復系統(tǒng)在崩潰前所做的數(shù)據(jù)更新。
總結(jié)
Command
模式是非常簡單而又優(yōu)雅的一種設計模式，它的根本目的在于將“行為請求者”與“行為實現(xiàn)者”解耦。
更多的設計模式文章可以訪問《
.NET設計模式系列文章
》
參考資料
Erich Gamma
等，《設計模式：可復用面向?qū)ο筌浖幕A(chǔ)》，機械工業(yè)出版社
Robert C.Martin
，《敏捷軟件開發(fā)：原則、模式與實踐》，清華大學出版社
閻宏，《Java與模式》，電子工業(yè)出版社
Alan Shalloway James R. Trott
，《Design Patterns Explained》，中國電力出版社
MSDN WebCast
《C#面向?qū)ο笤O計模式縱橫談(14)：Command命令模式(結(jié)構(gòu)型模式)》
袁劍，《領(lǐng)悟Web設計模式》
更多文章、技術(shù)交流、商務合作、聯(lián)系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯(lián)系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
