[设计模式] 状态模式



转载出处：

http://www.cnblogs.com/wangjq/archive/2012/07/16/2593485.html

http://www.cnblogs.com/wenjiang/p/3352041.html

1. 概述

　　当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。

2. 解决的问题

　　主要解决的是当控制一个对象状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同的一系列类当中，可以把复杂的逻辑判断简单化。

3. 模式中的角色

　　3.1 上下文环境（Context）：它定义了客户程序需要的接口并维护一个具体状态角色的实例，将与状态相关的操作委托给当前的Concrete State对象来处理。

　　3.2 抽象状态（State）：定义一个接口以封装使用上下文环境的的一个特定状态相关的行为。

　　3.3 具体状态（Concrete State）：实现抽象状态定义的接口。

4. 模式解读

　　4.1 状态模式的类图

　　

　　4.2 状态模式的代码实现

    /// <summary>
/// Context类，维护一个ConcreteState子类的实例，这个实例定义当前的状态。
/// </summary>
public class Context
    {
private State state;
/// <summary>
/// 定义Context的初始状态
/// </summary>
/// <param name="state"></param>
public Context(State state)
        {
this.state = state;
        }

/// <summary>
/// 可读写的状态属性，用于读取和设置新状态
/// </summary>
public State State
        {
get { return state; }
set { state = value; }
        }

/// <summary>
/// 对请求做处理，并设置下一个状态
/// </summary>
public void Request()
        {
            state.Handle(this);
        }
    }

/// <summary>
/// 抽象状态类，定义一个接口以封装与Context的一个特定状态相关的行为
/// </summary>
public abstract class State
    {
public abstract void Handle(Context context);
    }

/// <summary>
/// 具体状态类，每一个子类实现一个与Context的一个状态相关的行为
/// </summary>
public class ConcreteStateA : State
    {
/// <summary>
/// 设置ConcreteStateA的下一个状态是ConcreteStateB
/// </summary>
/// <param name="context"></param>
public override void Handle(Context context)
        {
            Console.WriteLine("当前状态是 A.");
            context.State = new ConcreteStateB();
        }
    }

public class ConcreteStateB : State
    {
/// <summary>
/// 设置ConcreteStateB的下一个状态是ConcreteSateA
/// </summary>
/// <param name="context"></param>
public override void Handle(Context context)
        {
            Console.WriteLine("当前状态是 B.");
            context.State = new ConcreteStateA();
        }
    }

　　4.3 客户端调用

    class Program
    {
static void Main(string[] args)
        {
// 设置Context的初始状态为ConcreteStateA
            Context context = new Context(new ConcreteStateA());

// 不断地进行请求，同时更改状态
            context.Request();
            context.Request();
            context.Request();
            context.Request();

            Console.Read();
        }
    }

　　运行结果

　　

5. 模式总结

　　5.1 优点

　　　　5.1.1 状态模式将与特定状态相关的行为局部化，并且将不同状态的行为分割开来。

　　　　5.1.2 所有状态相关的代码都存在于某个ConcereteState中，所以通过定义新的子类很容易地增加新的状态和转换。

　　　　5.1.3 状态模式通过把各种状态转移逻辑分不到State的子类之间，来减少相互间的依赖。

　　5.2 缺点

　　　　5.2.1 导致较多的ConcreteState子类

　　5.3 适用场景

　　　　5.3.1 当一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为时，就可以考虑使用状态模式来。

　　　　5.3.2 一个操作中含有庞大的分支结构，并且这些分支决定于对象的状态。

6. 应用举例：电灯有两个状态，开（亮）与关（不亮），下面就用状态模式来实现对电灯的控制。

　　6.1 类图

　

　　6.2 实现代码

    /// <summary>
/// 电灯类，对应模式中的Context类
/// </summary>
public class Light
    {
private LightState state;

public Light(LightState state)
        {
this.state = state;
        }

/// <summary>
/// 按下电灯开关
/// </summary>
public void PressSwich()
        {
            state.PressSwich(this);
        }

public LightState State
        {
get { return state; }
set { state = value; }
        }    
    }

/// <summary>
/// 抽象的电灯状态类，相当于State类
/// </summary>
public abstract class LightState
    {
public abstract void PressSwich(Light light);
    }

/// <summary>
/// 具体状态类, 开
/// </summary>
public class On : LightState
    {
/// <summary>
/// 在开状态下，按下开关则切换到关的状态。
/// </summary>
/// <param name="light"></param>
public override void PressSwich(Light light)
        {
            Console.WriteLine("Turn off the light.");

            light.State = new Off();
        }
    }

/// <summary>
/// 具体状态类，关
/// </summary>
public class Off: LightState
    {
/// <summary>
/// 在关状态下，按下开关则打开电灯。
/// </summary>
/// <param name="light"></param>
public override void PressSwich(Light light)
        {
            Console.WriteLine("Turn on the light.");

            light.State = new On();
        }
    }

　　6.3 客户端代码

    class Program
    {
static void Main(string[] args)
        {
// 初始化电灯，原始状态为关
            Light light = new Light(new Off());

// 第一次按下开关，打开电灯
            light.PressSwich();
// 第二次按下开关，关闭电灯
            light.PressSwich();

            Console.Read();
        }
    }

策略模式的孪生兄弟---状态模式

      人的机缘是神奇的，认识一个人就相当于打开了一个圈子，不管这个人是否在圈子中心，而这点，会在不经意间带给我们意想不到的作用。

      如果我们在编写代码的时候，遇到大量的条件判断的时候，可能会采用策略模式来优化结构，因为这时涉及到策略的选择，但有时候仔细查看下，就会发现，这些所谓的策略其实是对象的不同状态，更加明显的是，对象的某种状态也成为判断的条件。

      我们还是以一个例子入手。

      假设现在我们有一个饮水机，它有以下两个状态： 满桶，空桶。初始状态是满桶，容量是20。饮水机只有一个动作：press，每次press后都会使容量减1，一旦为0，则将状态设置为空桶，这时press没有水流出。

      要使用状态模式，我们必须明确两个东西：状态和每个状态下执行的动作。就像是饮水机，最基本的状态就是满桶和空桶，而这两个状态下，都可能要执行倒水这个动作，也就是press。如果饮水机的容量为0，则会进入空桶的状态。

      在状态模式中，因为所有的状态都要执行相应的动作，所以我们可以考虑将状态抽象出来。

      状态的抽象一般有两种形式：接口和抽象类。如果所有的状态都有共同的数据域，可以使用抽象类，但如果只是单纯的执行动作，就可以使用接口。

      这里我们就用接口。

public interface DispenserState {
void press();
}

     然后我们再定义满桶和空桶两个状态：

public class FullState implements DispenserState {

    @Override
public void press() {
        System.out.println("Water is pouring!");
    }
}

public class NullState implements DispenserState {

    @Override
public void press() {
        System.out.println("There is not water poured!");
    }
}

      接着我们再实现饮水机：

public class WaterDispenser {
private static int capacity = 20;
private static DispenserState dispenserState;

public WaterDispenser(DispenserState state) {
        dispenserState = state;
    }

private static void setState(DispenserState state) {
        dispenserState = state;
    }

public DispenserState getState() {
return dispenserState;
    }

public void press() {
        capacity--;
if (capacity <= 0) {
            setState(new NullState());
        }
        dispenserState.press();
    }
}

      接着我们再进行测试：

public class Test {
public static void main(String[] args) {
WaterDispenser dispenser = new WaterDispenser(new FullState());
for (int i = 0; i < 100; ++i) {
            dispenser.press();
        }
    }
}

     这是一个非常简单的应用场景：我们不断的press，饮水机里的水会越来越少，从满桶状态变成空桶状态。

     如果我们不使用状态模式，也可以解决这个问题：

public class WaterDispenser {
private static int capacity = 20;

public void press() {
        capacity--;
if (capacity <= 0) {
            System.out.println("There is not water poured!");
        } else {
            System.out.println("Water is pouring!");
        }
    }
}

     这样确实是更加简单，不需要有多余的接口和一系列的类，但这里的情况只有两种，如果是三种，五种，甚至更多，几十种，那我们到底需要多么可怕的if...else子句啊！而且，要是条件中再嵌套条件，简直就是难以想象！！

     状态模式的好处就是将我们从这个复杂的嵌套条件中脱离出来，但状态模式的坏处也是非常明显：需要管理一系列的状态类。
     状态模式的意图就是让每一个状态对修改关闭，允许对象在内部状态改变时改变它的行为，使对象看起来好像修改了它的类。

     让每一个状态对修改关闭，也就是让状态类来改变状态，即封装，我们只能通过向状态类发送消息来改变状态，至于怎么改变，则完全隐藏起来。

     允许对象在内部状态改变时改变它的行为，使对象看起来好像修改了它的类。其实，对象本身拥有一个状态类的对象集合，只要符合状态改变的条件，就可以将表示状态的状态类改变成下个状态类。从具体的代码来看，所谓的状态类的对象集合，其实就是我们的对象拥有一个状态类的引用，该引用可以指向任何状态类的对象集合的具体引用。对象本身一般都会有一个setState()方法，可以将状态修改成另一个状态。

      至于这个对象，我们可以给它一个专门的名词：Context，也就是上下文类。

      上下文是一个难以理解的词眼，放在具体的应用场景中更加直白点。

      这里我们的饮水机就是一个Context，它将自己的行为委托给状态对象执行，像是press()方法，就交给具体的状态对象state的press()方法执行。

      上下文类的明显特点就是拥有一个引用，然后通过该引用调用相应的方法。

      我们是如何区分不同的状态？就是通过每个状态不同的行为来区分，所以不同的状态都有相同的动作，但是这个动作的执行结果是不同的，而且执行结果还有可能会修改当前的状态。为了体现多态，摆脱对具体状态类的依赖，使用Context可以动态的替换状态类，就像策略模式一样。

      状态的转换不一定是放在Context中，有时候状态类本身也会自动切换状态。当状态的转换是固定的，像是这里的容量为0，就变成空桶状态，我们可以在Context中完成转换，但如果转换是动态的，也就是没有固定的判断条件，像是一完成就自动切换，我们可以放在状态类中。

      但将状态的切换放在状态类中，会让状态类间产生依赖，而且状态类还需要拥有Context类的引用才能切换状态，也就是采用观察者模式的方法来通知Context类更新状态。所以，是否要这样做，就看具体的编程环境以及我们的经验了。

      程序员的经验是非常重要的，它决定我们是否可以达到更高的境界，新手是在积累经验，等累积到一定的程度，编程的时候就基本靠经验的驱动了，什么是安全的代码，什么样的代码扩展性好，都会在不知不觉间体现出来，不需要特意从头脑中挖出来。

      状态对象也是可以共享的，但前提就是状态对象不能持有它们自己的内部状态，否则无法保证另一个线程得到的对象是正确的状态。所以，我们如果想要共享状态，需要把每个状态都指定到静态的实例变量中。

      状态模式的意图其实非常简单：将与状态有关的处理逻辑分散到代表对象状态的各个类中，但我们的Context类必须拥有这些状态对象集合的引用，这也就引出一个问题：实例化Context类对象会导致状态类对象集合初始化方面的问题，也就是对象的依赖问题。

      为了尽可能减少这方面的依赖，我们的Context类通常拥有的只是一个状态类的抽象引用，然后设置一个setter以便动态的更改状态类对象。

      如果不是使用对象，而是采用常量的方法：

private static final int FULL_STATE = 0;
private static final int NULL_STATE = 1;

      也可以使用enum将它们封装起来：

enum STATE{ NULL_STATE, FULL_STATE};

      采用这种做法是因为我们需要根据当前的状态自动跳转到下一个状态，比如说，饮水机可以在空桶的状态自动加水：

if(state == NULL_STATE){
       capacity++;
if(capacity == 20){
            state = FULL_STATE;
       }
}

     这种做法非茶馆常见，因为我们只是想要有一个状态的判断和切换的简单动作，并不需要特意创建一个对象，因为这些状态只是单纯的标识，没有任何的职责。但程序中出现过多的静态变量总是让人觉得这个程序的设计不具有良好的弹性，如果可以从这些状态中提取出抽象，可以考虑使用状态模式来优化我们的代码结构。

     之所以说状态模式是策略模式的孪生兄弟，是因为它们的UML图是一样的，但意图却完全不一样，策略模式是让用户指定更换的策略算法，而状态模式是状态在满足一定条件下的自动更换，用户无法指定状态，最多只能设置初始状态。