分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow

也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！

設計模式 ( 十七) 狀態模式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.實現

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

簡單地實現程式碼：

<?phpabstract 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.總結與分析

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

給我老師的人工智慧教程打call！http://blog.csdn.net/jiangjunshow