狀態模式 State 行爲型 設計模式（二十四）

狀態模式 State

 

人有喜怒哀樂，海綿寶寶也會有不一樣的時候，也會有不一樣的心情~

問題：上圖中，若是跟海綿寶寶開玩笑，那種狀況最可能被打？ 

 

看下面一個示例，演示了java中的多態特性

類A有方法action()

類B繼承了A 覆蓋了方法action()

類C繼承了A 覆蓋了方法action()

package state.example;
public class A {
    void action() {
        System.out.println("A.......");
    }
    public static void main(String[] args) {
        A a = new A();
        A b = new B();
        A c = new C();
        a.action();
        b.action();
        c.action();
        }
    }
    
class B extends A {
    @Override
    void action() {
        System.out.println("B.......");
        }
class C extends A {
    @Override
    void action() {
        System.out.println("C.......");
        }
}

類型都是A，可是卻由於內部的具體的子類類型不同，結果不同

 

海綿寶寶在不一樣心情狀態下，對同一件事情的處理態度多是不一樣的，生氣的時候跟他開玩笑極可能會被打。

一樣的類型A，因爲具體類型狀態的不一樣，給出的響應是不一樣的。

這就是狀態， 不少事物都有不一樣的狀態，不一樣的狀態可能會有不一樣的行爲，並且，狀態間是能夠切換的。

意圖

容許一個對象在其內部狀態改變時改變他的行爲。對象看起來彷佛修改了他的類。

別名：狀態對象（Objects for States)

 

其實就是 擁有狀態屬性，在不一樣的狀態下，呈現出不一樣的行爲，而且能夠靈活的切換狀態。

狀態： 一個對象的行爲取決於內部一個或者多個動態變化的屬性，這樣的屬性就叫作狀態。

有狀態的對象stateful： 這樣的對象就叫作有狀態的對象。

結構

不考慮Java語言的多態，如何達到「多態」的效果？

一種很天然的解決方案就是條件分支或者選擇語句，好比

int state = 0;

if(0 == state){
              //...
}else if(1 == state){
              //...
}else if(2 == state){
              //...
}else{
              //...
}

int類型的變量state 就是「有狀態的對象」，state的具體的值就是「狀態」。

狀態的切換依賴state變量的賦值，不一樣行爲的呈現藉助於條件分支。

 

顯然，若是業務邏輯複雜，將會有 繁瑣複雜的分支判斷

更有甚者，若是有多個狀態共同決定行爲，那麼豈不是 多個狀態的複雜組合了？

並且若是 新增長狀態，那麼就 須要修改代碼，添加一個新的 else if（），擴展性很差，不符合開閉原則。

 

咱們更但願的是可以達到「多態」的那種調用效果，方法調用與具體的行爲解耦。

調用者不須要關注具體的類型，在方法執行時，會具備真實類型的行爲。

至關於變形爲：

int state = 0;
state.action()；

 

看起來，看起來好像，看起來好像action()方法封裝了相似下面的判斷邏輯 （只是看起來，其實他只有他本身狀態下的行爲，不須要判斷）

if(0 == state){
//...
}else if(1 == state){
//...
}else if(2 == state){
//...
}else{
//...
}

這不就是上面的多態示例麼，若是A表示抽象的狀態，B和C表示具體的某種狀態

若是全部使用狀態的地方，都使用靜態類型A，就能夠根據實際類型達到多態的效果了。

 

因此說

狀態模式的根本在於藉助於OOP的多態機制，描述狀態，就能夠達到不一樣行爲的效果。

有了不一樣類型的狀態以後，還能夠進一步經過一箇中間類對他們進行管理，進而實現靈活的狀態切換。

 

因此一種經常使用的狀態模式結果以下

 

抽象狀態角色State

接口或者抽象類，定義狀態的抽象含義，而且給出狀態的行爲接口，這個接口被外界經過環境類調用

能夠持有Context的引用，經過Context完成狀態切換

具體狀態ConcreteState

實現了抽象狀態的描述，給出本身的行爲，每個子類型都表示一種具體的狀態

環境類角色Context

又叫作上下文，經過環境類Context對狀態進行管理

通常作法是將多種狀態定義爲他的靜態屬性，環境類中維護一個State，這是當前狀態，常常提供切換狀態的方法 

代碼示例

抽象的State，定義狀態行爲

package state;
public interface State {
void handle();
}

具體的狀態1 

package state;
public class ConcreateState1 implements State {
@Override
public void handle() {
System.out.println("state 1 do sth");
}
}

具體的狀態2

package state;
public class ConcreateState2 implements State {
    @Override
    public void handle() {
        System.out.println("state 2 do sth");
    }
}

環境類，內部封裝了兩個狀態

state爲當前狀態，初始時設置爲狀態1了

經過changeState方法進行切換

action（）方法爲封裝調用state的handle方法

package state;
public class Context {
    private final State STATE1 = new ConcreateState1();
    private final State STATE2 = new ConcreateState2();
    private State state = STATE1;
    public void action() {
        state.handle();
    }
    public void changeState(int stateValue) {
        if (1 == stateValue) {
        state = STATE1;
        } else if (2 == stateValue) {
        state = STATE2;
        }
    }
}

 

上面的示例代碼中，初始狀態爲狀態1 ，action調用狀態1，打印 state 1 do sth

狀態切換後，調用狀態2 

 

狀態模式的核心在於引入抽象狀態角色State，藉助於多態，實現不一樣的行爲，

而後藉助於環境類Context實現State的管理，以靈活切換狀態。

狀態的具體行爲，狀態切換的時機等等均可以根據實際狀況靈活處理，尤爲是什麼時候切換狀態，誰來負責切換狀態。

示例中，在環境類Context中建立了靜態的狀態對象，你能夠根據實際狀況動態的建立對象。

若是狀態頻繁變化，那麼事先建立全部狀態更合適，若是狀態設置後就不多變更，動態建立的形式或許更好。

狀態也能夠持有環境類的引用，能夠得到更多的便利性。

另外的示例

若是僅僅是狀態的提取，簡化複雜的狀態判斷邏輯，藉助於State角色就能夠完成

若是須要狀態的切換維護，或者要求狀態的順序等，總之對State的訪問須要增長更多的業務邏輯時，那麼就能夠藉助於Context對State進行管理

經過Context封裝維護當前狀態，也就是Context提供代理方法，代理對當前狀態State的直接訪問

這樣就能夠經過Context增長狀態切換，順序限制等更多的處理邏輯

 

好比下面邏輯，假設狀態1,2,3,4,5，經過下面的邏輯，就能夠控制狀態的切換順序，當前狀態推導出下一個狀態

void click(){

currentState.handle();

 

if(state == 1){

changeState(2);

}else if(state == 2){

changeState(3);

}

//.....

}

 

完整代碼

package state.order;
public interface State {
void handle();
}

package state.order;
public class ConcreateState1 implements State {
@Override
public void handle() {
System.out.println("state 1 do sth");
}
}

package state.order;
public class ConcreateState2 implements State {
@Override
public void handle() {
System.out.println("state 2 do sth");
}
}

package state.order;
public class ConcreateState3 implements State {
@Override
public void handle() {
System.out.println("state 3 do sth");
}
}

環境Context包括三種狀態，初始時當前狀態爲狀態1

每次方法調用，都會按照順序切換狀態

package state.order;
public class Context {
    private final State STATE1 = new ConcreateState1();
    private final State STATE2 = new ConcreateState2();
    private final State STATE3 = new ConcreateState3();
    private State state = STATE1;
    public void action() {
        state.handle();
        if (state == STATE1) {
            setState(STATE2);
        } else if (state == STATE2) {
            setState(STATE3);
        } else if (state == STATE3) {
            setState(STATE1);
        }
    }
    void setState(State state) {
        this.state = state;
    }
}

從上面的結果能夠看得出來，無論你調用多少次方法，他都會完成兩個任務，當前狀態處理，而後切換狀態

 

因此說，狀態的切換時機，場景，不一樣的方式將會有不少種不一樣的變化形式。

總結

狀態的本質很簡單，就是多態的體現，Java是純粹的面嚮對象語言，自然的具備多態的特性

因此，在 Java中，經過類的層次結構，就能夠直接造成一個「狀態」體系，頂級父類定義狀態的訪問接口，具體的實現類定義自身的狀態行爲。

 

不過狀態模式是多態的更進一步的抽象和概念提高，而不是單純的利用多態的特性。

狀態模式經過引入環境類Context，能夠對狀態進行管理，提供對狀態切換的支持。

經過Context 能夠實現對當前狀態的「 代理」，增長更多的處理邏輯

 

若是對象的行爲依賴他的狀態，狀態的改變致使行爲的變化，並且，代碼中含有大量的與對象有關的條件語句的處理邏輯

就能夠考慮使用狀態模式

 

狀態模式的重點就是將對象的狀態切換以及不一樣的狀態具備不一樣的行爲與客戶端進行了解耦

不一樣的狀態類型組成了狀態的體系結構，Context封裝了切換邏輯 ，能夠作到狀態的切換對客戶端透明

將全部的狀態切換行爲封裝到環境中，而不是分散在業務邏輯方法中，不論是維護性仍是擴展性的角度都大大提升。

並且使用起來也會很是靈活，Context也封裝代理了當前的狀態，可讓客戶端對狀態一無所知，如同一個代理人

客戶端再也不須要分狀況討論了，你就告訴Context須要作什麼就行了，他本身內部知道狀態，也能夠切換

 

狀態模式必然會致使大量的狀態類出現，若是狀態不多，你可能就不會用狀態模式了

並且運行時的對象個數也會增長不少

 

若是增長新的狀態類，對於那些涉及到狀態切換的代碼必然須要修改，不符合開閉原則

可是對於不修改狀態的代碼，由於經過抽象角色State，面向抽象編程，因此並不須要修改

修改狀態的代碼是面向具體類型，面向細節了，因此逃不掉了

 

狀態模式，就是多態以及多態的切換

開篇示例中的多態是Java語言層面上的多態，不一樣類型呈現不一樣的行爲。

狀態模式是設計思惟業務邏輯上的「多態」，根據狀態對象不一樣的產生不一樣狀態下的行爲，不是特指OOP中的多態。

狀態模式就是將「不一樣條件下的行爲」進行封裝，封裝後的對象就是狀態對象

 

原文地址: 狀態模式 State 行爲型 設計模式（二十四）