命令模式--設計模式
阿新 • • 發佈:2018-11-08
問題:
在軟體開發中,我們經常需要向某些物件傳送請求(呼叫其中的某個或某些方法),但是並不知道請求的接收者是誰,也不知道被請求的操作是哪個,此時,我們特別希望能夠以一種鬆耦合的方式來設計軟體,使得請求傳送者與請求接收者能夠消除彼此之間的耦合,讓物件之間的呼叫關係更加靈活,可以靈活地指定請求接收者以及被請求的操作。命令模式為此類問題提供了一個較為完美的解決方案。
命令模式定義如下:
命令模式(Command Pattern):將一個請求封裝為一個物件,從而讓我們可用不同的請求對客戶進行引數化;對請求排隊或者記錄請求日誌,以及支援可撤銷的操作。命令模式是一種物件行為型模式,其別名為動作(Action)模式或事務(Transaction)模式。
在命令模式結構圖中包含如下幾個角色:
● Command(抽象命令類):抽象命令類一般是一個抽象類或介面,在其中聲明瞭用於執行請求的execute()等方法,通過這些方法可以呼叫請求接收者的相關操作。
● ConcreteCommand(具體命令類):具體命令類是抽象命令類的子類,實現了在抽象命令類中宣告的方法,它對應具體的接收者物件,將接收者物件的動作繫結其中。在實現execute()方法時,將呼叫接收者物件的相關操作(Action)。
● Invoker(呼叫者):呼叫者即請求傳送者,它通過命令物件來執行請求。一個呼叫者並不需要在設計時確定其接收者,因此它只與抽象命令類之間存在關聯關係。在程式執行時可以將一個具體命令物件注入其中,再呼叫具體命令物件的execute()方法,從而實現間接呼叫請求接收者的相關操作。
● Receiver(接收者):接收者執行與請求相關的操作,它具體實現對請求的業務處理。命令模式的本質是對請求進行封裝,一個請求對應於一個命令,將發出命令的責任和執行命令的責任分割開。每一個命令都是一個操作:請求的一方發出請求要求執行一個操作;接收的一方收到請求,並執行相應的操作。命令模式允許請求的一方和接收的一方獨立開來,使得請求的一方不必知道接收請求的一方的介面,更不必知道請求如何被接收、操作是否被執行、何時被執行,以及是怎麼被執行的。
命令模式的關鍵在於引入了抽象命令類,請求傳送者針對抽象命令類程式設計,只有實現了抽象命令類的具體命令才與請求接收者相關聯。在最簡單的抽象命令類中只包含了一個抽的execute()方法,每個具體命令類將一個Receiver型別的物件作為一個例項變數進行儲存,從而具體指定一個請求的接收者,不同的具體命令類提供了execute()方法的不同實現,並呼叫不同接收者的請求處理方法。 典型的抽象命令類程式碼如下所示:
abstract class Command {
public abstract void execute();
}
對於請求傳送者即呼叫者而言,將針對抽象命令類進行程式設計,可以通過構造注入或者設值注入的方式在執行時傳入具體命令類物件,並在業務方法中呼叫命令物件的execute()方法,其典
型程式碼如下所示:
class Invoker {
private Command command;
//構造注入
public Invoker(Command command) {
this.command = command;
}
//設值注入
public void setCommand(Command command) {
this.command = command;
}
//業務方法,用於呼叫命令類的execute()方法
public void call() {
command.execute();
}
}
具體命令類繼承了抽象命令類,它與請求接收者相關聯,實現了在抽象命令類中宣告的
execute()方法,並在實現時呼叫接收者的請求響應方法action(),其典型程式碼如下所示:
class ConcreteCommand extends Command {
private Receiver receiver; //維持一個對請求接收者物件的引用
public void execute() {
receiver.action(); //呼叫請求接收者的業務處理方法action()
}
}
請求接收者Receiver類具體實現對請求的業務處理,它提供了action()方法,用於執行與請求相
關的操作,其典型程式碼如下所示:
class Receiver {
public void action() {
//具體操作
}
}
命令佇列的實現
有時候我們需要將多個請求排隊,當一個請求傳送者傳送一個請求時,將不止一個請求接收者產生響應,這些請求接收者將逐個執行業務方法,完成對請求的處理。此時,我們可以通過命令佇列來實現。