24天学会设计模式------状态模式

林炳文Evankaka原创作品。转载请注明出处http://blog.csdn.net/evankaka

一、状态模式

1、定义

    状态模式 ：允许一个对象在其内部状态改变时改变它的行为，即不同的状态对应不同的行为。 这需要将状态单独抽象成一个对象。

2、意图

    在很多情况下，一个对象的行为取决于一个或多个动态变化的属性，这样的属性叫做状态。这样的对象叫做有状态的 (stateful)对象。这样的对象状态是从事先定义好的一系列值中取出的。当一个这样的对象与外部事件产生互动时，其内部状态就会改变，从而使得系统的行为也随之发生变化。

 4、模式中的角色

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

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

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

5、适用性

    在下面的两种情况下均可使用State模式:

    (1)一个对象的行为取决于它的状态, 并且它必须在运行时刻根据状态改变它的行为。

     (2)代码中包含大量与对象状态有关的条件语句:一个操作中含有庞大的多分支的条件（if else(或switch case)语句，且这些分支依赖于该对象的状态。这个状态通常用一个或多个枚举常量表示。通常 , 有多个操作包含这一相同的条件结构。 State模式将每一个条件分支放入一个独立的类中。这使得你可以根据对象自身的情况将对象的状态作为一个对象，这一对象可以不依赖于其他对象而独立变化。

二、使用范例

//灯的类public class Light {private LightState m_state;//灯的状态/*初始化为一个灯的颜色*/public Light(LightState m_state){this.m_state=m_state;}/*改变灯的颜色*/public void  setLight(LightState m_state) {this.m_state=m_state;}/*得到当前灯的颜色*/public void lightColor(){m_state.lightColor(this);}}

//灯的颜色抽象接口public interface LightState  {/*改变灯*/public abstract void lightColor(Light m_litht);}

//红灯public class RedState implements LightState {@Overridepublic void lightColor(Light m_light) {System.out.println("红灯亮了");m_light.setLight(new GreenLight());//红灯亮完，设置为绿灯}}

//绿灯public class GreenLight implements LightState {@Overridepublic void lightColor(Light m_light) {System.out.println("绿灯亮了");m_light.setLight(new YellowState());//绿灯亮完，设置为黄灯}}

//黄灯public class YellowState implements LightState {@Overridepublic void lightColor(Light m_light) {System.out.println("黄灯亮了");m_light.setLight(new RedState());//黄灯亮完，设置为红灯}}

/*** 文件名:Main.java* 描述：状态讲解* 创建人:林炳文* 日 期:2015.1.27**/public class Main {public static void main(String[] args) {LightState m_LightState=new RedState();//灯初始货为红色Light m_light=new Light(m_LightState);m_light.lightColor();//输出当前灯颜色，并改变下次输出灯的颜色m_light.lightColor();m_light.lightColor();m_light.lightColor();}}

输出：

红灯亮了
绿灯亮了
黄灯亮了
红灯亮了

三、优缺点

1、优点

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

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

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

2、缺点

（1）状态模式的使用必然会增加系统类和对象的个数。
（2）状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。

四、与策略模式区别

1、相似之处：

1. 添加新的状态或策略都很容易，而且不需要修改使用它们的Context对象。
2. 它们都让你的代码符合OCP原则。在状态模式和策略模式中，Context对象对修改是关闭的，添加新的状态或策略，都不需要修改Context。
3. 正如状态模式中的Context会有初始状态一样，策略模式同样有默认策略。
4. 状态模式以不同的状态封装不同的行为，而策略模式以不同的策略封装不同的行为。
5. 它们都依赖子类去实现相关行为。

2、不同之处

现在我们知道，状态模式和策略模式的结构是相似的，但它们的意图不同。让我们重温一下它们的主要不同之处：

1. 策略模式封装了一组相关算法，它允许Client在运行时使用可互换的行为；状态模式帮助一个类在不同的状态显示不同的行为。
2. 状态模式封装了对象的状态，而策略模式封装算法或策略。因为状态是跟对象密切相关的，它不能被重用；而通过从Context中分离出策略或算法，我们可以重用它们。
3. 在状态模式中，每个状态通过持有Context的引用，来实现状态转移；但是每个策略都不持有Context的引用，它们只是被Context使用。
4. 策略实现可以作为参数传递给使用它的对象，例如Collections.sort()，它的参数包含一个Comparator策略。另一方面，状态是Context对象自己的一部分，随着时间的推移，Context对象从一个状态转移到另一个状态。
5. 虽然它们都符合OCP原则，策略模式也符合SRP原则（单一职责原则），因为每个策略都封装自己的算法，且不依赖其他策略。一个策略的改变，并不会导致其他策略的变化。
6. 另一个理论上的不同：策略模式定义了对象“怎么做”的部分。例如，排序对象怎么对数据排序。状态模式定义了对象“是什么”和“什么时候做”的部分。例如，对象处于什么状态，什么时候处在某个特定的状态。
7. 状态模式中很好的定义了状态转移的次序；而策略模式并无此需要：Client可以自由的选择任何策略。
8. 一些常见的策略模式的例子是封装算法，例如排序算法，加密算法或者压缩算法。如果你看到你的代码需要使用不同类型的相关算法，那么考虑使用策略模式吧。而识别何时使用状态模式是很简单的：如果你需要管理状态和状态转移，但不想使用大量嵌套的条件语句，那么就是它了。
9. 最后但最重要的一个不同之处是，策略的改变由Client完成；而状态的改变，由Context或状态自己。