一、引言
起初餐館吃飯都是客人和廚師直接溝通，菜譜是一樣的，可是客人多了的時候，有的客人可能有急事不吃了要退單，還有的客人點很多菜需要記錄類別和次序等現象，這時服務員角色的出現解決了問題。那麼面對某些無法抵禦變化的「緊耦合」的場景如何做程式設計呢？命令模式設計便出現了，使得「行為請求者」與「行為實現者」解耦，以便適應變化，讓物件之間呼叫關係更加靈活。下面請看今天要學習的命令模式：
二、命令模式
定義：將乙個請求封裝為乙個物件，從而使可用不同的請求對客戶進行引數化；對請求排隊或記錄請求日誌，以及支援可撤銷的操作。
下面是結構圖：
下面是**demo：
//view code接收者類
class
receiver
}//命令抽象類
abstract
class
command
//執行命令操作
public
abstract
void
execute();
}//具體命令類
class
concretecommand : command
public
override
void
execute()
}//排程類 要求命令執行這個請求
class
invoker
//執行命令
public
void
executecommand()
}class
program
}
優點：
1.降低系統耦合度，解除請求者和實現者的耦合
2.組合命令，將多個命令裝配成乙個組合命令，即較容易設計乙個命令佇列和巨集命令
3.增加乙個新的命令很容易，無需改變現有的類
4.對請求排隊或記錄請求日誌，支援可撤銷的操作
缺點：
1.針對每乙個命令設計乙個具體的命令類，可能導致系統有過多的具體命令類
使用場景：
1.系統需要請求者和實現者解耦，呼叫者和接收者不直接互動
2.需要在不同的時間支援請求，對請求排隊。乙個命令物件和原來的請求者有不同的生命期。換言之，原來的請求發出者可能已經不在了，而命令物件本身仍然是活動的。這時命令接收者可以在本地，也可以在網路的另乙個位址。命令物件可以在序列之後傳送到另一台機器上去。
3.系統需要支援命令的撤銷（undo）。命令物件可以把狀態儲存起來，等客戶端需要撤銷命令所產生效果時，可以呼叫undo方法，把命令所產生的效果撤銷掉
4.如果乙個系統要將系統中所有資料訊息更新到日誌裡，以便在系統崩潰時，可以根據日誌裡讀回所有資料的更新命令，重新呼叫方法一條一條執行命令，從而恢復系統在崩潰前所作的資料更新
5.使用命令模式作為「callback」在物件導向系統中的替代。"callback"即先將乙個函式註冊上，然後在以後呼叫此函式
物件導向程式設計思想 狀態模式
一 引言 上篇部落格中學習了中介者模式，我們留下了乙個問題，當出現多個玩家需要輸贏狀態條件判斷時，可不可以不去修改中介者類，因為如果每新增乙個條件判斷，就要修改中介者類，破壞了封裝，違背開閉原則。今天我們學習的內容就是要解決這種業務場景，狀態模式 二 狀態模式 定義 當乙個物件的內在狀態改變時允許改...
物件導向程式設計思想 外觀模式
一 引言 每逢去吃午飯路上，幾個同事都要討論一番投資理財的事情，時間久之，小白的我才勉強了解到 與 的區別，是自身直接與某只 交易，可以通過分紅或者低買高賣獲利 自身需要分析 多隻 的 如圖示一 而 是把錢交給 公司，有專業人員幫你分析 或債券等幫你理財 自身不需要直接關注 了，見圖示二 圖示一 圖...
物件導向程式設計思想
舉個最簡單點的例子來區分 有一天要請客吃飯，怎麼辦？有兩個方法 1 買菜，買調料，買肉，買酒水，然後下廚房動手炒菜 2 去飯店，點個 看出來區別了嗎？方法1是面向過程，方法2是物件導向。物件導向有什麼優勢？首先不需要知道各種菜式是怎麼做的，降低了耦合性。如果突然想換 了，對於方法1可能不太容易，因為...