一、引言
上篇部落格中學習了中介者模式，我們留下了乙個問題，當出現多個玩家需要輸贏狀態條件判斷時，可不可以不去修改中介者類，因為如果每新增乙個條件判斷，就要修改中介者類，破壞了封裝，違背開閉原則。今天我們學習的內容就是要解決這種業務場景，狀態模式
二、狀態模式
定義：當乙個物件的內在狀態改變時允許改變其行為，這個物件看起來像是改變了其類
下面是狀態模式的結構圖：
下面是**demo：
//維護乙個concretestate子類的例項，這個例項定義當前狀態
class
context
//可讀寫的state
public
state state
set"
); }
}//對請求做處理，並設定下乙個狀態
public
void
request()
}//抽象狀態類 定義乙個介面以封裝與context的乙個特定狀態相關的行為
1.確保了新增狀態及對應的行為時，不是去修改很長一大串if...else..邏輯判斷。消除龐大的分支語句
2.把各種狀態轉移邏輯分布到state類的子類中，更加利於擴充套件
下面是大話設計模式中的例子：
場景：上午狀態好，中午想睡覺，下午漸恢復，晚上苦煎熬
classwork
public
inthour;
public
inthour
set
}public
bool
finish;
public
bool
taskisfinish
set
}//設定當前狀態
public
void
setstate(state state)
public
void
writeprogram()
}abstract
class
state
class
forenoonstate : state
點，上午工作，精神充沛
",work.hour);
}else}}
class
noonstate : state
點，肚子餓了，午休，犯睏
",work.hour);
}else}}
class
afternoonstate: state
點，下午狀態還不錯，繼續努力
", work.hour);
}else}}
class
eveningstate: state
else
點，要加班哦,疲累至極
", work.hour);
}else}}
}class
sleepingstate: state
點，不行了，睡著了
", work.hour);}}
class
resetstate: state
點，下班了，回家了
分析：如果老闆哪天要求「20點以後強制下班」，只需要新增加乙個強制下班狀態，稍微修改下傍晚狀態類就可以了，而不會影響到其它狀態類
下面是上篇部落格中留下的問題，結合狀態模式和中介者模式處理，下面是**demo：
abstractclass
mediator
public
mediator(state state)
public
void
add(colleague colleague)
public
void
remove(colleague colleague)
public
void win(int
number)
}class
concretemediator : mediator
}abstract
class
state
class
concretestateawin : state
public
override
void win(int
number)
else}}
}class
concretestatebwin : state
public
override
void win(int
number)
else}}
}class
initstate : state
public
override
void win(int
number)
}abstract
class
colleague
public
abstract
void win(int
number,mediator mediator);
}class
concretecolleaguea : colleague
}class
concretecolleagueb : colleague
}class
program
");console.writeline($
"b的數量為");
分析：ok，解決了上面部落格中的提出的兩個問題，具體問題見上篇部落格
優點：1.將狀態判斷邏輯分到每個狀態裡面，減少了相互依賴，簡化邏輯
2.當有新的狀態出現時，可以通過新增狀態來進行擴充套件，擴充套件性好
缺點：1.當狀態較多時，concretestate類較多，增加系統開銷
適用場景：
1.當乙個物件的行為取決於它的狀態，並且必須在執行時刻根據狀態改變行為時，就可以考慮狀態模式
2.乙個操作中有龐大的分支結構，並且這些分支結構取決於它的狀態
物件導向程式設計思想 命令模式
一 引言 起初餐館吃飯都是客人和廚師直接溝通，菜譜是一樣的，可是客人多了的時候，有的客人可能有急事不吃了要退單，還有的客人點很多菜需要記錄類別和次序等現象，這時服務員角色的出現解決了問題。那麼面對某些無法抵禦變化的 緊耦合 的場景如何做程式設計呢？命令模式設計便出現了，使得 行為請求者 與 行為實現...
物件導向程式設計思想 外觀模式
一 引言 每逢去吃午飯路上，幾個同事都要討論一番投資理財的事情，時間久之，小白的我才勉強了解到 與 的區別，是自身直接與某只 交易，可以通過分紅或者低買高賣獲利 自身需要分析 多隻 的 如圖示一 而 是把錢交給 公司，有專業人員幫你分析 或債券等幫你理財 自身不需要直接關注 了，見圖示二 圖示一 圖...
物件導向程式設計思想
舉個最簡單點的例子來區分 有一天要請客吃飯，怎麼辦？有兩個方法 1 買菜，買調料，買肉，買酒水，然後下廚房動手炒菜 2 去飯店，點個 看出來區別了嗎？方法1是面向過程，方法2是物件導向。物件導向有什麼優勢？首先不需要知道各種菜式是怎麼做的，降低了耦合性。如果突然想換 了，對於方法1可能不太容易，因為...