?命令模式

一：定義

將一個請求封裝為一個對象(即我們創(chuàng)建的Command對象），從而使你可用不同的請求對客戶進行參數(shù)化; 對請求排隊或記錄請求日志，以及支持可撤銷的操作。

二：實現(xiàn)

解決的問題

　　在軟件系統(tǒng)中，行為請求者與行為實現(xiàn)者通常是一種緊耦合的關(guān)系，但某些場合，比如需要對行為進行記錄、撤銷或重做、事務(wù)等處理時，這種無法抵御變化的緊耦合的設(shè)計就不太合適。

模式中角色

　　1 抽象命令（Command）：定義命令的接口，聲明執(zhí)行的方法。

　　2 具體命令（ConcreteCommand）：具體命令，實現(xiàn)要執(zhí)行的方法，它通常是“虛”的實現(xiàn)；通常會有接收者，并調(diào)用接收者的功能來完成命令要執(zhí)行的操作。

　　3 接收者（Receiver）：真正執(zhí)行命令的對象。任何類都可能成為一個接收者，只要能實現(xiàn)命令要求實現(xiàn)的相應(yīng)功能。

　　4 調(diào)用者（Invoker）：要求命令對象執(zhí)行請求，通常會持有命令對象，可以持有很多的命令對象。這個是客戶端真正觸發(fā)命令并要求命令執(zhí)行相應(yīng)操作的地方，也就是說相當于使用命令對象的入口。

　　5 客戶端（Client）：命令由客戶端來創(chuàng)建，并設(shè)置命令的接收者。

三：模式分析

4.4 模式分析

　　　　4.4.1 本質(zhì)：對命令進行封裝，將發(fā)出命令與執(zhí)行命令的責任分開。

　　　　4.4.2 每一個命令都是一個操作：請求的一方發(fā)出請求，要求執(zhí)行一個操作；接收的一方收到請求，并執(zhí)行操作。

　　　　4.4.3 請求方和接收方獨立開來，使得請求的一方不必知道接收請求的一方的接口，更不必知道請求是怎么被接收，以及操作是否被執(zhí)行、何時被執(zhí)行，以及是怎么被執(zhí)行的。

　　　　4.4.4 使請求本身成為一個對象，這個對象和其它對象一樣可以被存儲和傳遞。

　　　　4.4.5 命令模式的關(guān)鍵在于引入了抽象命令接口，且發(fā)送者針對抽象命令接口編程，只有實現(xiàn)了抽象命令接口的具體命令才能與接收者相關(guān)聯(lián)。　

5. 模式總結(jié)

　　5.1 優(yōu)點

　　　　5.1.1 解除了請求者與實現(xiàn)者之間的耦合，降低了系統(tǒng)的耦合度。

　　　　5.1.2 對請求排隊或記錄請求日志，支持撤銷操作。

　　　　5.1.3 可以容易地設(shè)計一個組合命令。

　　　　5.1.4 新命令可以容易地加入到系統(tǒng)中。

　　5.2 缺點

　　　　5.2.1 因為針對每一個命令都需要設(shè)計一個具體命令類，使用命令模式可能會導(dǎo)致系統(tǒng)有過多的具體命令類。

　　5.3 適用場景

　　　　5.3.1 當需要對行為進行“記錄、撤銷/重做”等處理時。

　　　　5.3.2 系統(tǒng)需要將請求者和接收者解耦，使得調(diào)用者和接收者不直接交互。

　　　　5.3.3 系統(tǒng)需要在不同時間指定請求、請求排隊和執(zhí)行請求。

　　　　5.3.4 系統(tǒng)需要將一組操作組合在一起，即支持宏命令。

6. 應(yīng)用舉例：銀行帳號的存款、提款

?

轉(zhuǎn)載于:https://www.cnblogs.com/wycBlog/p/7426886.html

總結(jié)

以上是生活随笔為你收集整理的（35）23种设计模式研究之六【命令模式】的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。