狀態模式：允許物件在內部狀態改變時改變它的行為，物件看起來好像修改了它的類
當控制乙個物件狀態轉換的條件表示式過於複雜時，把狀態的判斷邏輯轉移至表示不同狀態的一系列類中
我們來看一下自動售票機的使用場景：
圓圈表示自動售票機所處的狀態
箭頭線表示乘客的操作（也是自動售票機從乙個狀態切換到另乙個狀態所需的操作）
狀態抽象為自動售票機類的引數，操作抽象為自動售票機類的方法
}執行結果如下
投幣成功，請選擇線路
退幣成功
投幣成功，請選擇線路
路線選擇成功，正在出票
已出票，請拿走您的車票
}執行結果如下
投幣成功，請選擇線路
退幣成功
投幣成功，請選擇線路
路線選擇成功，請確認
請重新選擇線路
路線選擇成功，請確認
線路已確認，正在出票中
已出票，請拿走您的車票
1，改動量很大，自動售票機類的每個方法，都要增加對新增狀態的判斷
2，每個方法糅合了大量的if else以便對所有狀態提供正確的響應，在修改的過程中極易出錯，能否將不同狀態的行為進行分割？
3，狀態經常會發生變動，如果狀態發生變動，能否只修改狀態相關類？而不需要修改自動售票機類
4，自動售票機所處的狀態為私有屬性，對外是不可見的，乘客類僅關心可以進行的操作，並不關心其內部所處狀態以及狀態之間的變換
因此我們可以將自動售票機的狀態從自動售票機類中提取出來單獨進行封裝
}消除了龐大的條件分支語句，通過把各種狀態轉移邏輯分散到state介面的具體實現類中，來降低耦合度，每個方法的具體實現將十分精簡
類的數量變多，這是為了獲得擴充套件性而付出的代價，其實真正重要的是暴漏給使用者的類的數量
看一下狀態模式的類圖：
狀態模式和策略模式從類圖上來看沒有區別，本質上真的有什麼區別麼？
策略模式：除非告訴物件使用另乙個策略，否則物件會一直使用其初始化時被賦予的策略
狀態模式：初始化時告訴類從哪個狀態開始，隨著時間的變化，狀態也會自動發生變化，大量條件判斷語句的替代方式
變化多端的狀態模式 State Pattern
現在寫字樓越建越高，碼農上個班不但要擠個地鐵，還要擠個電梯。電梯的執行簡單有這麼幾個狀態 執行 停止 關閉 開啟，電梯想要正常的執行，就必須得遵循一定的規則，例如執行的時候不能開門，開門狀態不能執行。按照平常的邏輯，分別建立open,close,run,stop四個方法，方法裡通過switch當前的...
設計模式 狀態模式
狀態模式 當乙個物件的內在狀態改變時允許改變其行為，這個物件看起來像是改變了其類。狀態模式主要解決的是當控制乙個物件狀態轉換的條件表示式過於複雜時的情況，把狀態的判斷邏輯轉移到表示不同狀態的一些列類當中，可以把複雜的判斷邏輯簡化。當乙個物件的行為取決於它的狀態，並且它必須在執行時刻根據狀態改變它的行...
設計模式 狀態模式
1.概述 當乙個物件的內在狀態改變時允許改變其行為，這個物件看起來像是改變了其類。2.解決的問題 主要解決的是當控制乙個物件狀態轉換的條件表示式過於複雜時的情況。把狀態的判斷邏輯轉移到表示不同的一系列類當中，可以把複雜的邏輯判斷簡單化。3.模式中的角色 3.1 上下文環境 context 它定義了客...