設計模式（14）命令模式

命令模式，用來對請求的傳送者和請求的接收者進行解耦的一種設計模式，為什麼叫命令模式呢？因為在應用該模式時，引入了乙個命令物件。

命令模式有三個角色，請求傳送者，命令物件，請求的接收者（處理者），誰來給請求傳送者和接收者解耦呢，命令物件，所以我們一思考就知道命令模式應該是這樣的：

請求傳送者傳送請求，為了增強擴充套件性，需要面向抽象程式設計，所以首先有乙個抽象命令物件，當然，還要有具體命令物件來對應具體接收者，從而使不同命令得到不同處理。

舉例說明（例子參照《c#設計模式劉偉胡志剛閻朝坤》開關示例）：隔壁老王幫隔壁鄰居修開關，隔壁也是倒霉，風扇開關和電燈泡開關都壞了，隔壁老王上街買開關，要買兩個，然而他不用特意買兩個不同的開關，他只需買兩個一模一樣的開關就行，修的時候，使用不同電線連線不同電器，燈泡和風扇自然都能正常工作。

在上面例子中，開關（請求傳送者，傳送通電，斷電請求），電線（命令物件）封裝請求，燈泡或風扇（請求接收者處理者）處理請求。通過電線，很好的將請求傳送者和接受者進行了解耦，這樣好處很大，燈泡壞了只換燈泡，開關壞了只換開關即可。

命令模式uml類圖：

lampcommand和lamp是同生共死關係，所以是組合關係。

示例**：

請求傳送者：

/****
* 請求傳送者（開關）
* @author wjw
* */
public class sender 
/***
* 開關開
*/public void open()
/***
* 開關關
*/public void close()
}

抽象命令類：

/*****
* 抽象命令類
* @author wjw
* */
public abstract class abstractcommand

電燈命令類：

/****
* 電燈命令物件，封裝電燈（命令接收者）
* @author wjw
* */
public class lampcommand extends abstractcommand
@override
public void open() 
@override
public void close() 
}

風扇命令類：

public class fancommand extends abstractcommand
@override
public void open() 
@override
public void close() 
}

電燈類：

/****
* 電燈（請求接收者）
* @author wjw
* */
public class lamp 
public void closelamp()
}

風扇類：

/****
* 風扇類（請求處理者）
* @author wjw
* */
public class fan 
public void closefan()
}

main類：

public class main 
}

執行結果：

開燈！關燈！開風扇！

關風扇！

通過以上示例**可以看出，我們開關和燈泡或者風扇沒有耦合，相同的開關，既可以用在燈泡上，又可以用在風扇上，乙個電燈泡，可以使用a型開關，也可以使用b型開關，其中的原理就是多了乙個中介軟體，用來給他倆解耦，**請求。

說明：命令模式就是將乙個具體的請求封裝成乙個物件，將請求的傳送者與接收者解耦。

我們為什麼要用命令模式這個設計模式呢？設想這樣乙個場景，某廠家生產的電燈，開關和燈泡是連在一起的，燈泡10000元，開關10塊，某天開關壞了，廠家說要把燈泡一起換了，你同意嗎？正常人估計會把廠家踹一邊，自己在家找個風扇不用的開關給電燈換上，繼續使用。所以只要有正常人的思維理解命令模式不難。

如有錯誤，歡迎指正

end

設計模式（14） 命令模式

設計模式（14） 命令模式

設計模式（14） 命令模式

設計模式之組合模式14

相關推薦

設計模式（14）命令模式

設計模式（14）命令模式

設計模式（14）命令模式