接下來講命令模式，這個模式從名字上看就很簡單，命令嘛，老大發命令，小兵執行就是了，確實是這個意思，但是更深化了，用模式來描述真是是世界的命令情況。我們就以專案組為例子來講述命令模式。
專案的成員分工也是採用了常規的分工方式，分為需求組（requirement group，簡稱rg）、美工組（page group,簡稱pg）、**組（我們內部還有乙個比較優雅的名字：邏輯實現組，這裡使用大家經常稱呼的名稱吧，英文縮寫叫code group，簡稱cg），加上專案經理，剛開始的時候客戶（也就是旅行社，甲方）還是很樂意和我們每個組**，比如和需求組討論需求，和美工討論頁面，和**組討論實現，告訴他們修改這裡，刪除這裡，增加這些等等，這是一種比較常見的甲乙方合作模式，甲方深入到乙方的專案開發中。
使用者對介面不滿意，就去找美工組談；介面也談過了，應該沒什麼大問題了吧。過了一天後，客戶又讓**組過去，說是資料庫設計問題，然後又叫美工過去，布置了一堆命令，這個我就不一一寫了，大家應該能夠體會到，你做過專案的話，這種體會更深，客戶讓修改你不修改？專案不想做了你!
但是問題來了，我們修改可以，但是每次都是叫乙個組去，布置個任務，然後出計畫，次次都這樣，如果讓你當甲方也就是客戶，你煩不煩？而且這種方式很容易出錯誤呀，而且還真發生過，客戶把美工叫過去了，要刪除，可美工說需求是這麼寫的，然後客戶又命令需求組過去，一次次的折騰，客戶也煩躁了，於是直接抓住專案經理說：「我不管你們內部怎麼安排，你就給我找個接頭人，我告訴他怎麼做，刪除頁面了，增加功能了，你們內部怎麼處理，我就告訴他我要幹什麼就成了…」。於是就用到了命令模式。
命令模式（command）：將乙個請求封裝成乙個物件，從而使你可用不同的請求對客戶進行引數化；對請求排隊或記錄請求日誌，以及支援可撤銷的操作。來看下類圖：
類圖中增加了不少，看著也比較清晰，比較簡單的（command抽象類與group抽象類是沒有關聯關係的，與group的三個實現類是有關聯關係，為了線條不交叉就直接畫上父類有關係），增加的幾個類說明如下：
command抽象類：客戶發給我們的命令，定義三個工作組的成員變數，供子類使用；定義乙個抽象方法execute，由子類來實現；
invoker實現類:專案接頭人，setcomand接受客戶發給我們的命令，action方法是執行客戶的命令（方法名寫成是action是與command的execute區分開，避免混淆）
receiver類：即group
分析一下原理：以客戶需要增加需求命令為例。客戶端約見接頭人invoker，發出乙個增加需求命令「command command = new addrequirementcommand();」，接頭人接下命令"invoker.setcommand(addrequirementcommand)",完了回公司之後接頭人就要將客戶的要求傳達給需求組，於是在invoker就執行他的action方法，其方法內容無非就是客戶傳入的command.excute(),最後的勞動力還是底層的requirementgroup（即命令模式裡的另乙個重要的類receiver）執行（苦逼的程式設計師）！
一句話概括命令模式：介面卡和策略的結合，把請求和物件分開！
單例模式小記 原創
中國的歷史上很少出現兩個皇帝並存的時期，是有，但不多，那我們就認為皇帝是個單例模式，在這個場景中，有皇帝，有大臣，大臣是天天要上朝參見皇帝的，今天參拜的皇帝應該和昨天 前天的一樣 過渡期的不考慮，別找茬哦 大臣磕完頭，抬頭一看，嗨，還是昨天那個皇帝，單例模式，絕對的單例模式，先看類圖 單例模式最大的...
模板方法模式小記 原創
模板方法模式，定義乙個操作中的演算法的骨架，而將一些步驟延遲到子類中。模板方法使得子類中可以不改變的乙個演算法的結構即可重定義該演算法的某些特定步驟。首先來看下模板方法模式的結構圖 abstractclass是抽象類，其實也就是一抽象模板，定義並實現了乙個模板方法。即templetemethod。這...
單例模式小記 原創
中國的歷史上很少出現兩個皇帝並存的時期，是有，但不多，那我們就認為皇帝是個單例模式，在這個場景中，有皇帝，有大臣，大臣是天天要上朝參見皇帝的，今天參拜的皇帝應該和昨天 前天的一樣 過渡期的不考慮，別找茬哦 大臣磕完頭，抬頭一看，嗨，還是昨天那個皇帝，單例模式，絕對的單例模式，先看類圖 單例模式最大的...