設計模式 ( 十七) 狀態模式State（對象行為型）

設計模式 ( 十七) 狀態模式State（對象行為型）

1.概述

在軟件開發過程中，應用程序可能會根據不同的情況作出不同的處理。最直接的解決方案是將這些所有可能發生的情況全都考慮到。然后使用if… ellse語句來做狀態判斷來進行不同情況的處理。但是對復雜狀態的判斷就顯得“力不從心了”。隨著增加新的狀態或者修改一個狀體（if else(或switch case)語句的增多或者修改）可能會引起很大的修改，而程序的可讀性，擴展性也會變得很弱。維護也會很麻煩。那么我就考慮只修改自身狀態的模式。

例子1：按鈕來控制一個電梯的狀態，一個電梯開們，關門，停，運行。每一種狀態改變，都有可能要根據其他狀態來更新處理。例如，開門狀體，你不能在運行的時候開門，而是在電梯定下后才能開門。

例子2：我們給一部手機打電話，就可能出現這幾種情況：用戶開機，用戶關機，用戶欠費停機，用戶消戶等。 所以當我們撥打這個號碼的時候：系統就要判斷，該用戶是否在開機且不忙狀態，又或者是關機，欠費等狀態。但不管是那種狀態我們都應給出對應的處理操作。

2.問題

對象如何在每一種狀態下表現出不同的行為？

3.解決方案

狀態模式：允許一個對象在其內部狀態改變時改變它的行為。對象看起來似乎修改了它的類。

在很多情況下，一個對象的行為取決于一個或多個動態變化的屬性，這樣的屬性叫做狀態，這樣的對象叫做有狀態的(stateful)對象，這樣的對象狀態是從事先定義好的一系列值中取出的。當一個這樣的對象與外部事件產生互動時，其內部狀態就會改變，從而使得系統的行為也隨之發生變化。

4.適用性

在下面的兩種情況下均可使用State模式:
1) ? 一個對象的行為取決于它的狀態, 并且它必須在運行時刻根據狀態改變它的行為。
2) ? 代碼中包含大量與對象狀態有關的條件語句:一個操作中含有龐大的多分支的條件（if else(或switch case)語句，且這些分支依賴于該對象的狀態。這個狀態通常用一個或多個枚舉常量表示。通常 , 有多個操作包含這一相同的條件結構。 State模式將每一個條件分支放入一個獨立的類中。這使得你可以根據對象自身的情況將對象的狀態作為一個對象，這一對象可以不依賴于其他對象而獨立變化。

5.結構

6.模式的組成

環境類（Context）:  定義客戶感興趣的接口。維護一個ConcreteState子類的實例，這個實例定義當前狀態。
抽象狀態類（State）:  定義一個接口以封裝與Context的一個特定狀態相關的行為。
具體狀態類（ConcreteState）:  每一子類實現一個與Context的一個狀態相關的行為。

7.效果

State模式有下面一些效果:
狀態模式的優點：
1 ) 它將與特定狀態相關的行為局部化，并且將不同狀態的行為分割開來: State模式將所有與一個特定的狀態相關的行為都放入一個對象中。因為所有與狀態相關的代碼都存在于某一個State子類中, 所以通過定義新的子類可以很容易的增加新的狀態和轉換。另一個方法是使用數據值定義內部狀態并且讓 Context操作來顯式地檢查這些數據。但這樣將會使整個Context的實現中遍布看起來很相似的條件if else語句或switch case語句。增加一個新的狀態可能需要改變若干個操作, 這就使得維護變得復雜了。State模式避免了這個問題, 但可能會引入另一個問題, 因為該模式將不同狀態的行為分布在多個State子類中。這就增加了子類的數目，相對于單個類的實現來說不夠緊湊。但是如果有許多狀態時這樣的分布實際上更好一些, 否則需要使用巨大的條件語句。正如很長的過程一樣，巨大的條件語句是不受歡迎的。它們形成一大整塊并且使得代碼不夠清晰，這又使得它們難以修改和擴展。 State模式提供了一個更好的方法來組織與特定狀態相關的代碼。決定狀態轉移的邏輯不在單塊的 i f或s w i t c h語句中, 而是分布在State子類之間。將每一個狀態轉換和動作封裝到一個類中，就把著眼點從執行狀態提高到整個對象的狀態。這將使代碼結構化并使其意圖更加清晰。

2) 它使得狀態轉換顯式化: 當一個對象僅以內部數據值來定義當前狀態時 , 其狀態僅表現為對一些變量的賦值，這不夠明確。為不同的狀態引入獨立的對象使得轉換變得更加明確。而且, State對象可保證Context不會發生內部狀態不一致的情況，因為從 Context的角度看，狀態轉換是原子的—只需重新綁定一個變量(即Context的State對象變量)，而無需為多個變量賦值

3) State對象可被共享 如果State對象沒有實例變量—即它們表示的狀態完全以它們的類型來編碼—那么各Context對象可以共享一個State對象。當狀態以這種方式被共享時, 它們必然是沒有內部狀態, 只有行為的輕量級對象。

狀態模式的缺點:
1) 狀態模式的使用必然會增加系統類和對象的個數。
2) 狀態模式的結構與實現都較為復雜，如果使用不當將導致程序結構和代碼的混亂。

8.實現

我們用電梯的例子來說明：

簡單地實現代碼：

<?php  
abstract class ILift {  
    //電梯的四個狀態  
    const OPENING_STATE = 1;  //門敞狀態  
    const CLOSING_STATE = 2;  //門閉狀態  
    const RUNNING_STATE = 3;  //運行狀態  
    const STOPPING_STATE = 4; //停止狀態；  
  
      
    //設置電梯的狀態  
    public abstract function setState($state);  
  
    //首先電梯門開啟動作  
    public abstract function open();  
  
    //電梯門有開啟，那當然也就有關閉了  
    public abstract function close();  
  
    //電梯要能上能下，跑起來  
    public abstract function run();  
  
    //電梯還要能停下來，停不下來那就扯淡了  
    public abstract function stop();  
}  
  
/** 
 * 電梯的實現類  
 */   
class Lift extends  ILift {  
    private $state;  
  
    public function setState($state) {  
        $this->state = $state;  
    }  
    //電梯門關閉  
    public function close() {  
        //電梯在什么狀態下才能關閉  
        switch($this->state){  
            case ILift::OPENING_STATE:  //如果是則可以關門，同時修改電梯狀態  
                $this->setState(ILift::CLOSING_STATE);  
            break;  
            case ILift::CLOSING_STATE:  //如果電梯就是關門狀態，則什么都不做  
                //do nothing;  
                return ;  
            break;  
            case ILift::RUNNING_STATE: //如果是正在運行，門本來就是關閉的，也說明都不做  
                //do nothing;  
                return ;  
            break;  
            case ILift::STOPPING_STATE:  //如果是停止狀態，本也是關閉的，什么也不做  
                //do nothing;  
                return ;  
            break;  
        }  
                echo 'Lift colse <br>';  
    }  
  
    //電梯門開啟  
    public function open() {  
        //電梯在什么狀態才能開啟  
        switch($this->state){  
            case ILift::OPENING_STATE: //如果已經在門敞狀態，則什么都不做  
                //do nothing;  
                return ;  
            break;  
            case ILift::CLOSING_STATE: //如是電梯時關閉狀態，則可以開啟  
                $this->setState(ILift::OPENING_STATE);  
            break;  
            case ILift::RUNNING_STATE: //正在運行狀態，則不能開門，什么都不做  
            //do nothing;  
                return ;  
            break;  
            case ILift::STOPPING_STATE: //停止狀態，淡然要開門了  
                $this->setState(ILift::OPENING_STATE);  
            break;  
        }  
        echo 'Lift open <br>';  
    }  
    ///電梯開始跑起來  
    public function run() {  
        switch($this->state){  
            case ILift::OPENING_STATE: //如果已經在門敞狀態，則不你能運行，什么都不做  
                //do nothing;  
                return ;  
            break;  
            case ILift::CLOSING_STATE: //如是電梯時關閉狀態，則可以運行  
                $this->setState(ILift::RUNNING_STATE);  
            break;  
            case ILift::RUNNING_STATE: //正在運行狀態，則什么都不做  
                //do nothing;  
                return ;  
            break;  
            case ILift::STOPPING_STATE: //停止狀態，可以運行  
                $this->setState(ILift::RUNNING_STATE);  
        }  
        echo 'Lift run <br>';  
    }  
  
    //電梯停止  
    public function stop() {  
        switch($this->state){  
            case ILift::OPENING_STATE: //如果已經在門敞狀態，那肯定要先停下來的，什么都不做  
                //do nothing;  
                return ;  
            break;  
            case ILift::CLOSING_STATE: //如是電梯時關閉狀態，則當然可以停止了  
                $this->setState(ILift::CLOSING_STATE);  
            break;  
            case ILift::RUNNING_STATE: //正在運行狀態，有運行當然那也就有停止了  
                $this->setState(ILift::CLOSING_STATE);  
            break;  
            case ILift::STOPPING_STATE: //停止狀態，什么都不做  
                //do nothing;  
                return ;  
            break;  
        }  
        echo 'Lift stop <br>';  
    }  
      
}  
$lift = new Lift();   
     
//電梯的初始條件應該是停止狀態   
$lift->setState(ILift::STOPPING_STATE);   
//首先是電梯門開啟，人進去   
$lift->open();   
     
//然后電梯門關閉   
$lift->close();   
     
//再然后，電梯跑起來，向上或者向下   
$lift->run();      
 //最后到達目的地，電梯挺下來   
$lift->stop();

顯然我們已經完成了我們的基本業務操作，但是，我們在程序中使用了大量的switch…case這樣的判斷（if…else也是一樣),首先是程序的可閱讀性很差，其次擴展非常不方便。一旦我們有新的狀態加入的話，例如新加通電和斷點狀態。我們勢必要在每個業務方法里邊增加相應的case語句。也就是四個函數open，close，run，stop都需要修改相應case語句。

狀態模式：把不同狀態的操作分散到不同的狀態對象里去完成。看看狀態類的uml類圖：

代碼實現：

<?php  
/** 
 *  
 * 定義一個電梯的接口  
 */   
abstract class LiftState{  
  
    //定義一個環境角色，也就是封裝狀態的變換引起的功能變化  
    protected  $_context;  
  
    public function setContext(Context $context){  
        $this->_context = $context;  
    }  
  
    //首先電梯門開啟動作  
    public abstract function open();  
  
    //電梯門有開啟，那當然也就有關閉了  
    public abstract function close();  
  
    //電梯要能上能下，跑起來  
    public abstract function run();  
  
    //電梯還要能停下來，停不下來那就扯淡了  
    public abstract function stop();  
  
}  
  
  
/** 
 * 環境類:定義客戶感興趣的接口。維護一個ConcreteState子類的實例，這個實例定義當前狀態。 
 */   
class Context {  
    //定義出所有的電梯狀態  
    static  $openningState = null;  
    static  $closeingState = null;  
    static  $runningState  = null;  
    static  $stoppingState = null;  
  
    public function __construct() {  
        self::$openningState = new OpenningState();  
        self::$closeingState = new ClosingState();  
        self::$runningState =  new RunningState();  
        self::$stoppingState = new StoppingState();  
  
    }  
  
    //定一個當前電梯狀態  
    private  $_liftState;  
  
    public function getLiftState() {  
        return $this->_liftState;  
    }  
  
    public function setLiftState($liftState) {  
        $this->_liftState = $liftState;  
        //把當前的環境通知到各個實現類中  
        $this->_liftState->setContext($this);  
    }  
  
  
    public function open(){  
        $this->_liftState->open();  
    }  
  
    public function close(){  
        $this->_liftState->close();  
    }  
  
    public function run(){  
        $this->_liftState->run();  
    }  
  
    public function stop(){  
        $this->_liftState->stop();  
    }  
}  
  
/** 
 * 在電梯門開啟的狀態下能做什么事情  
 */   
class OpenningState extends LiftState {  
  
    /** 
     * 開啟當然可以關閉了，我就想測試一下電梯門開關功能 
     * 
     */  
    public function close() {  
        //狀態修改  
        $this->_context->setLiftState(Context::$closeingState);  
        //動作委托為CloseState來執行  
        $this->_context->getLiftState()->close();  
    }  
  
    //打開電梯門  
    public function open() {  
        echo 'lift open...', '<br/>';  
    }  
    //門開著電梯就想跑，這電梯，嚇死你！  
    public function run() {  
        //do nothing;  
    }  
  
    //開門還不停止？  
    public function stop() {  
        //do nothing;  
    }  
  
}  
  
/** 
 * 電梯門關閉以后，電梯可以做哪些事情  
 */   
class ClosingState extends LiftState {  
  
    //電梯門關閉，這是關閉狀態要實現的動作  
    public function close() {  
        echo 'lift close...', '<br/>';  
  
    }  
    //電梯門關了再打開，逗你玩呢，那這個允許呀  
    public function open() {  
        $this->_context->setLiftState(Context::$openningState);  //置為門敞狀態  
        $this->_context->getLiftState()->open();  
    }  
  
    //電梯門關了就跑，這是再正常不過了  
    public function run() {  
        $this->_context->setLiftState(Context::$runningState); //設置為運行狀態；  
        $this->_context->getLiftState()->run();  
    }  
  
    //電梯門關著，我就不按樓層  
      
    public function stop() {  
        $this->_context->setLiftState(Context::$stoppingState);  //設置為停止狀態；  
        $this->_context->getLiftState()->stop();  
    }  
  
}  
  
/** 
 * 電梯在運行狀態下能做哪些動作  
 */   
class RunningState extends LiftState {  
  
    //電梯門關閉？這是肯定了  
    public function close() {  
        //do nothing  
    }  
  
    //運行的時候開電梯門？你瘋了！電梯不會給你開的  
    public function open() {  
        //do nothing  
    }  
  
    //這是在運行狀態下要實現的方法  
    public function run() {  
        echo 'lift run...', '<br/>';  
    }  
  
    //這個事絕對是合理的，光運行不停止還有誰敢做這個電梯？！估計只有上帝了  
    public function stop() {  
        $this->_context->setLiftState(Context::$stoppingState); //環境設置為停止狀態；  
        $this->_context->getLiftState()->stop();  
    }  
  
}  
  
  
  
/** 
 * 在停止狀態下能做什么事情  
 */   
class StoppingState extends LiftState {  
  
    //停止狀態關門？電梯門本來就是關著的！  
    public function close() {  
        //do nothing;  
    }  
  
    //停止狀態，開門，那是要的！  
    public function open() {  
        $this->_context->setLiftState(Context::$openningState);  
        $this->_context->getLiftState()->open();  
    }  
    //停止狀態再跑起來，正常的很  
    public function run() {  
        $this->_context->setLiftState(Context::$runningState);  
        $this->_context->getLiftState()->run();  
    }  
    //停止狀態是怎么發生的呢？當然是停止方法執行了  
    public function stop() {  
        echo 'lift stop...', '<br/>';  
    }  
  
}  
  
/** 
 * 模擬電梯的動作  
 */   
class Client {  
  
    public static function main() {  
        $context = new Context();  
        $context->setLiftState(new ClosingState());  
  
        $context->open();  
        $context->close();  
        $context->run();  
        $context->stop();  
    }  
}  
Client::main();

9.與其他相關模式

1）職責鏈模式，
職責鏈模式和狀態模式都可以解決If分支語句過多，
從定義來看，狀態模式是一個對象的內在狀態發生改變（一個對象，相對比較穩定，處理完一個對象下一個對象的處理一般都已確定），
而職責鏈模式是多個對象之間的改變（多個對象之間的話，就會出現某個對象不存在的現在，就像我們舉例的公司請假流程，經理可能不在公司情況），這也說明他們兩個模式處理的情況不同。
這兩個設計模式最大的區別就是狀態模式是讓各個狀態對象自己知道其下一個處理的對象是誰。
而職責鏈模式中的各個對象并不指定其下一個處理的對象到底是誰，只有在客戶端才設定。
用我們通俗的編程語言來說，就是
狀態模式：
  相當于If else if else；
  設計路線：各個State類的內部實現(相當于If，else If內的條件)
  執行時通過State調用Context方法來執行。
職責鏈模式：
  相當于Swich case
  設計路線：客戶設定，每個子類(case)的參數是下一個子類(case)。
  使用時，向鏈的第一個子類的執行方法傳遞參數就可以。
就像對設計模式的總結，有的人采用的是狀態模式，從頭到尾，提前一定定義好下一個處理的對象是誰，而我采用的是職責鏈模式，隨時都有可能調整鏈的順序。

2） 策略模式：（http://www.cnblogs.com/Mainz/archive/2007/12/15/996081.html）（狀態模式是策略模式的孿生兄弟）
        狀態模式和策略模式的實現方法非常類似，都是利用多態把一些操作分配到一組相關的簡單的類中，因此很多人認為這兩種模式實際上是相同的。
然而在現實世界中，策略（如促銷一種商品的策略）和狀態（如同一個按鈕來控制一個電梯的狀態，又如手機界面中一個按鈕來控制手機）是兩種完全不同的思想。當我們對狀態和策略進行建模時，這種差異會導致完全不同的問題。例如，對狀態進行建模時，狀態遷移是一個核心內容；然而，在選擇策略時，遷移與此毫無關系。另外，策略模式允許一個客戶選擇或提供一種策略，而這種思想在狀態模式中完全沒有。
       一個策略是一個計劃或方案，通過執行這個計劃或方案，我們可以在給定的輸入條件下達到一個特定的目標。策略是一組方案，他們可以相互替換；選擇一個策略，獲得策略的輸出。策略模式用于隨不同外部環境采取不同行為的場合。我們可以參考微軟企業庫底層Object Builder的創建對象的strategy實現方式。而狀態模式不同，對一個狀態特別重要的對象，通過狀態機來建模一個對象的狀態；狀態模式處理的核心問題是狀態的遷移，因為在對象存在很多狀態情況下，對各個business flow，各個狀態之間跳轉和遷移過程都是及其復雜的。
       例如一個工作流，審批一個文件，存在新建、提交、已修改、HR部門審批中、老板審批中、HR審批失敗、老板審批失敗等狀態，涉及多個角色交互，涉及很多事件，這種情況下用狀態模式(狀態機)來建模更加合適；把各個狀態和相應的實現步驟封裝成一組簡單的繼承自一個接口或抽象類的類，通過另外的一個Context來操作他們之間的自動狀態變換，通過event來自動實現各個狀態之間的跳轉。在整個生命周期中存在一個狀態的遷移曲線，這個遷移曲線對客戶是透明的。我們可以參考微軟最新的WWF 狀態機工作流實現思想。
      在狀態模式中，狀態的變遷是由對象的內部條件決定，外界只需關心其接口，不必關心其狀態對象的創建和轉化；
而策略模式里，采取何種策略由外部條件(C)決定。
      他們應用場景（目的）卻不一樣，State模式重在強調對象內部狀態的變化改變對象的行為，Strategy模式重在外部對策略的選擇，策略的選擇由外部條件決定，
也就是說算法的動態的切換。但由于它們的結構是如此的相似，我們可以認為“狀態模式是完全封裝且自修改的策略模式”。即狀態模式是封裝對象內部的狀態的，而策略模式是封裝算法族的

10.總結與分析

       狀態模式的主要優點在于封裝了轉換規則，并枚舉可能的狀態，它將所有與某個狀態有關的行為放到一個類中，并且可以方便地增加新的狀態，只需要改變對象狀態即可改變對象的行為，還可以讓多個環境對象共享一個狀態對象，從而減少系統中對象的個數；其缺點在于使用狀態模式會增加系統類和對象的個數，且狀態模式的結構與實現都較為復雜，如果使用不當將導致程序結構和代碼的混亂，對于可以切換狀態的狀態模式不滿足“開閉原則”的要求。

轉自：http://blog.csdn.net/hguisu/article/details/7557252