所有開發(fā)人員都應該知道的3種設計模式類型之三(含代碼示例)

　　類型 3：行為 - 命令設計模式

　　行為設計模式側重于類和對象如何相互通信。命令模式的主要重點是在相關方(閱讀：類)之間灌輸更高程度的松散耦合。

　　呃......什么?

　　耦合是兩個(或多個)相互交互的類相互作用的方式。這些類交互的理想方案是它們不會嚴重依賴彼此。這就是松散耦合。因此，松散耦合的更好定義是，相互連接的類，彼此使用最少。

　　當需要發(fā)送請求而沒有有意識地知道您要求什么或接收者是誰時，就產(chǎn)生了對這種模式的需求。

　　在此模式中，調用類與實際執(zhí)行操作的類分離。調用程序類僅具有可調用方法 execute，該方法在客戶端請求它時運行必要的命令。

　　讓我們舉一個基本的真實例子，在一家高檔餐廳點餐。隨著流程的進行，您將訂單(命令)交給服務員(調用者)，然后服務員將其交給廚師(接收者)，以便您可以獲得食物?？赡苈犉饋砗芎唵?..但有點麻煩的代碼。

　　這個想法很簡單，但編碼是繞鼻子走的。

　　命令設計模式類圖

　　技術端的操作流程是，你做一個具體的命令，實現(xiàn)命令接口，要求接收方完成一個動作，然后把命令發(fā)送給調用者。調用者是知道何時發(fā)出此命令的人。廚師是唯一知道在給定特定命令/命令時該怎么做的人。因此，當運行調用方的執(zhí)行方法時，它反過來會導致命令對象的執(zhí)行方法在接收方上運行，從而完成必要的操作。

　　我們需要執(zhí)行的是;

　　接口命令

　　實現(xiàn)命令接口的類順序

　　類服務員(調用者)

　　A級廚師(接收器)

　　所以，編碼是這樣的：

　　廚師，接收者

　　命令，接口

　　命令，具體命令

　　服務員，調用者

　　您，客戶

　　如上所示，客戶下訂單并將接收者設置為廚師。訂單被發(fā)送給服務員，服務員將知道何時執(zhí)行訂單(即何時向廚師下達烹飪訂單)。當調用程序被執(zhí)行時，Orders的執(zhí)行方法在接收器上運行(即，廚師被賦予烹飪意大利面?或烘烤蛋糕的命令?)。