在狀態模式(State Pattern)中,類的行爲是基於它的狀態改變的。這種類型的設計模式屬於行爲型模式。
在狀態模式中,咱們建立表示各類狀態的對象和一個行爲隨着狀態對象改變而改變的 context 對象。git
意圖:容許對象在內部狀態發生改變時改變它的行爲,對象看起來好像修改了它的類。
主要解決:對象的行爲依賴於它的狀態(屬性),而且能夠根據它的狀態改變而改變它的相關行爲。
什麼時候使用:代碼中包含大量與對象狀態有關的條件語句。
如何解決:將各類具體的狀態類抽象出來。
關鍵代碼:一般命令模式的接口中只有一個方法。而狀態模式的接口中有一個或者多個方法。並且,狀態模式的實現類的方法,通常返回值,或者是改變實例變量的值。也就是說,狀態模式通常和對象的狀態有關。實現類的方法有不一樣的功能,覆蓋接口中的方法。狀態模式和命令模式同樣,也能夠用於消除 if...else 等條件選擇語句。
應用實例: 一、打籃球的時候運動員能夠有正常狀態、不正常狀態和超常狀態。 二、曾侯乙編鐘中,'鍾是抽象接口','鍾A'等是具體狀態,'曾侯乙編鐘'是具體環境(Context)。
優勢: 一、封裝了轉換規則。 二、枚舉可能的狀態,在枚舉狀態以前須要肯定狀態種類。 三、將全部與某個狀態有關的行爲放到一個類中,而且能夠方便地增長新的狀態,只須要改變對象狀態便可改變對象的行爲。 四、容許狀態轉換邏輯與狀態對象合成一體,而不是某一個巨大的條件語句塊。 五、可讓多個環境對象共享一個狀態對象,從而減小系統中對象的個數。
缺點: 一、狀態模式的使用必然會增長系統類和對象的個數。 二、狀態模式的結構與實現都較爲複雜,若是使用不當將致使程序結構和代碼的混亂。 三、狀態模式對"開閉原則"的支持並不太好,對於能夠切換狀態的狀態模式,增長新的狀態類須要修改那些負責狀態轉換的源代碼,不然沒法切換到新增狀態,並且修改某個狀態類的行爲也需修改對應類的源代碼。
使用場景: 一、行爲隨狀態改變而改變的場景。 二、條件、分支語句的代替者。
注意事項:在行爲受狀態約束的時候使用狀態模式,並且狀態不超過 5 個。github
咱們將建立一個 State 接口和實現了 State 接口的實體狀態類。Context 是一個帶有某個狀態的類。
StatePatternDemo,咱們的演示類使用 Context 和狀態對象來演示 Context 在狀態改變時的行爲變化。設計模式
具體代碼參見https://github.com/Hp1512/Lea...spa