大話設計命令模式

每個模式都在傳遞著一種與眾不同的程式設計理念。每次都彷彿是站在巨人的上，一步步的學習，積土成山。

最近學習了命令模式，喜歡它很簡單：開篇從小菜大鳥吃肉串談起，慢慢的吸引著我的注意力，因為感興趣，所以有了進一步的研究。

【命令模式】

1.定義：將乙個請求封裝為乙個物件，從而使你可用不同的請求對客戶進行引數化；對請求排隊或記錄請求日誌，以及支援可撤銷的操作。

2.如圖所示：

很簡單，抽象出來命令類，然後定義乙個實現命令類的介面。與此有直接聯絡的是命令執行者和命令發出者，但是根據弱耦合原則，具體的命令執行者和命令的發出者之間沒有直接的關聯，invoker類實現了命令的上傳下達，是命令得以實現的關鍵因素。

3.個人理解

**總是在需求的變化中不斷優化的。

at first：大鳥和小菜去街邊小攤上吃燒烤，大家也都親歷過在大街上買烤串：消費者提出消費請求-燒烤老闆根據需求執行燒烤動作-一手交錢一手交貨。這對於小批量的消費人群來說，沒有什麼不合理的地方，但是隨著消費人群的擴大，消費量的增加，就會給燒烤老闆帶來一定的壓力，如果老闆足夠精明還好，要是記性不好的話，就會造成不必要的損失。拽個設計模式術語：這叫做耦合性太強。

//烤肉串者
public class barbecure
//烤雞翅
public void bakechickenwing()
}

then：【燒烤店vs燒烤攤】因為不太滿意燒烤攤老闆的服務，小菜建議去燒烤店吃，在這裡就不一樣了，燒烤店裡有專門的服務人員來記錄顧客需求並且發出消費通知，形成日誌記錄各種需求，達到有跡可循的目的，不會因為記不清楚而算錯帳了。於是形成了如下需求模式——松耦合設計

//抽象命令類
public abstract class command
abstract public void excutecommand();
}//服務員類
public class waiter
public void notify()
}

抽象出來了服務員類（用於記錄顧客需求資訊，形成日誌資料），服務員要做的是：當顧客點完餐後通知廚房去做。這樣就避免了顧客直接與燒烤老闆的聯絡，也就減少了不必要的糾紛。但是，這樣問題就又來了，如果**不充足，在這裡需要有乙個很長時間的資訊確認時間，也就是說物料不充足時，不應該是顧客來判斷是否還有，應該是服務員提供物料**資訊，這樣才算是「全心全意為人民服務」——優化的松耦合設計

today：人性化的服務滿足了消費者的需求。繼續對**進行優化設計：將物料**資訊全部提供給服務員，這樣在顧客點餐的時候不會出現不必要的麻煩。使用命令模式可以很好地解決這個問題。

//服務員類
public class waiter
else
}//取消訂單
public void cancelorder(command command)
//通知全部執行
public void notify()}}

這樣，就萬事俱備啦。

總結一下命令模式的優點：

1.能比較容易的設計乙個命令佇列；

2.在需要的情況下，可以比較容易的命令記入日誌

3.允許接收請求的一方決定是否要否決請求

4.可以容易地實現對請求的撤銷和重做；

5.由於加進新的具體命令類不影響其他的類，因此增加新的具體命令類很容易。

6.命令模式把請求乙個操作的物件與知道怎麼執行乙個操作的物件分割開。

敏捷開發原則告訴我們，不要為**新增基於猜測的、實際不需要的功能，如果不清楚乙個系統是否需要命令模式，一般就不要著急去實現它，事實上，在需要的時候通過重構實現這個模式並不困難，只有在真正需要如撤銷/恢復等功能是，把原來的**重構為命令模式才有意義。

【學習感受】

最近一直在學習大話設計模式，我也說不清怎樣算是學懂了、學透了。每次新接觸一種設計模式，總是會先看一遍課本，理解了模式的思想之後再去實現書本上的例子，能大致理解模式的思想，但是對於客戶端的**實現卻覺得有點艱難，可能是理論還沒有聯絡實踐的緣故，難免有一些茫然不知所措。還是先土豆土豆燉著吧，慢慢的總是會大徹大悟的。。。

大話設計命令模式

大話設計模式命令模式

大話設計模式命令模式

大話設計模式命令模式

大話設計 命令模式

大話設計模式 命令模式

大話設計模式 命令模式

大話設計模式 命令模式

相關推薦

大話設計命令模式

大話設計模式命令模式

大話設計模式命令模式

大話設計模式命令模式