状态模式State（对象行为型）

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

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]  view plain  copy

 print ?

1. <?php  
2. abstract class ILift {  
3.     //电梯的四个状态  
4.     const OPENING_STATE = 1;  //门敞状态  
5.     const CLOSING_STATE = 2;  //门闭状态  
6.     const RUNNING_STATE = 3;  //运行状态  
7.     const STOPPING_STATE = 4; //停止状态；  
8.   
9.       
10.     //设置电梯的状态  
11.     public abstract function setState($state);  
12.   
13.     //首先电梯门开启动作  
14.     public abstract function open();  
15.   
16.     //电梯门有开启，那当然也就有关闭了  
17.     public abstract function close();  
18.   
19.     //电梯要能上能下，跑起来  
20.     public abstract function run();  
21.   
22.     //电梯还要能停下来，停不下来那就扯淡了  
23.     public abstract function stop();  
24. }  
25.   
26. /** 
27.  * 电梯的实现类  
28.  */   
29. class Lift extends  ILift {  
30.     private $state;  
31.   
32.     public function setState($state) {  
33.         $this->state = $state;  
34.     }  
35.     //电梯门关闭  
36.     public function close() {  
37.         //电梯在什么状态下才能关闭  
38.         switch($this->state){  
39.             case ILift::OPENING_STATE:  //如果是则可以关门，同时修改电梯状态  
40.                 $this->setState(ILift::CLOSING_STATE);  
41.             break;  
42.             case ILift::CLOSING_STATE:  //如果电梯就是关门状态，则什么都不做  
43.                 //do nothing;  
44.                 return ;  
45.             break;  
46.             case ILift::RUNNING_STATE: //如果是正在运行，门本来就是关闭的，也说明都不做  
47.                 //do nothing;  
48.                 return ;  
49.             break;  
50.             case ILift::STOPPING_STATE:  //如果是停止状态，本也是关闭的，什么也不做  
51.                 //do nothing;  
52.                 return ;  
53.             break;  
54.         }  
55.                 echo