设计模式-状态模式

1. 什么时候使用状态模式

   通过前面的阐述，我们基本上了解了状态模式的样子。那我们什么时候使用状态模式呢？来看看Martin Fowler的这个重构：Replace Type Code with State/Stategy 你有一个type code，它会影响class的行为，但你无法使用subclassing。

   在你的类里面有个型别码来表示对象的当前状态，这个对象的行为通常依赖这个状态，而且在运行的时候这个状态会改变，那么对象的行为在运行的时候也要跟着改变。一般我们会使用if/else或者switch来根据这个型别码来执行相关操作，现在我们有更好的方式来处理。

2. 状态模式概述
   1. 状态模式用于解决系统中复杂对象的状态转换以及不同状态下行为的封装问题。当系统中某个对象存在多个状态，这些状态之间可以进行转换，而且对象在不同状态下行为不相同时可以使用状态模式。状态模式将一个对象的状态从该对象中分离出来，封装到专门的状态类中，使得对象状态可以灵活变化，对于客户端而言，无须关心对象状态的转换以及对象所处的当前状态，无论对于何种状态的对象，客户端都可以一致处理。
   3. 状态模式定义如下：

      状态模式(State Pattern)：允许一个对象在其内部状态改变时改变它的行为，对象看起来似乎修改了它的类。其别名为状态对象(Objects for States)，状态模式是一种对象行为型模式。

3. 状态和策略的异同

   有人会说，状态模式和策略模式是如此的相似，何必又分开呢？关键在于状态模式和策略模式的意图，状态模式是封装对象内部的状态的，而策略模式是封装算法族的。而且状态模式往往有这种表现：状态影响着对象当前的行为，行为也会倒过来改变对象的状态，这个相互影响是发生内部，也就是说状态模式中对象的行为是由对象的状态驱动的，而策略模式却不同，每次我们往往只使用一种策略来配置当前的系统，改变策略都是由外力来改变的，要使用哪种算法是由外部对象(客户)来驱动的。

4. 最后经理还总结了：要使用状态模式首先要总结出我们操作的接口(就是鼠标那些点击，双击操作)，保证这个接口稳定，如果这个接口经常变化那么就不建议采用状态模式。
5. 2. 
   3. 环境类实际上是真正拥有状态的对象，我们只是将环境类中与状态有关的代码提取出来封装到专门的状态类中。在状态模式结构图中，环境类Context与抽象状态类State之间存在单向关联关系，在Context中定义了一个State对象。在实际使用时，它们之间可能存在更为复杂的关系，State与Context之间可能也存在依赖或者关联关系。

            

   4. 在状态模式的使用过程中，一个对象的状态之间还可以进行相互转换，通常有两种实现状态转换的方式：

   5.        (1) 统一由环境类来负责状态之间的转换，此时，环境类还充当了状态管理器(State Manager)角色，在环境类的业务方法中通过对某些属性值的判断实现状态转换，还可以提供一个专门的方法用于实现属性判断和状态转换，如下代码片段所示：

   6.     ……  
               public void changeState() {  
              //判断属性值，根据属性值进行状态转换  
               if (value == 0) {  
                  this.setState(new ConcreteStateA());  
              }  
              else if (value == 1) {  
                  this.setState(new ConcreteStateB());  
              }  
                 ......  
          }  
             ……  

       

   7. (2) 由具体状态类来负责状态之间的转换，可以在具体状态类的业务方法中判断环境类的某些属性值再根据情况为环境类设置新的状态对象，实现状态转换，同样，也可以提供一个专门的方法来负责属性值的判断和状态转换。此时，状态类与环境类之间就将存在依赖或关联关系，因为状态类需要访问环境类中的属性值，如下代码片段所示：
      

      1. ……  
              public void changeState(Context ctx) {  
             //根据环境对象中的属性值进行状态转换  
              if (ctx.getValue() == 1) {  
                 ctx.setState(new ConcreteStateB());  
             }  
             else if (ctx.getValue() == 2) {  
                 ctx.setState(new ConcreteStateC());  
             }  
                ......  
         }  

          

   8. 使用环境类实现状态转换

             在状态模式中实现状态转换时，具体状态类可通过调用环境类Context的setState()方法进行状态的转换操作，也可以统一由环境类Context来实现状态的转换。此时，增加新的具体状态类可能需要修改其他具体状态类或者环境类的源代码，否则系统无法转换到新增状态。但是对于客户端来说，无须关心状态类，可以为环境类设置默认的状态类，而将状态的转换工作交给具体状态类或环境类来完成，具体的转换细节对于客户端而言是透明的。

             在上面的“银行账户状态转换”实例中，我们通过具体状态类来实现状态的转换，在每一个具体状态类中都包含一个stateCheck()方法，在该方法内部实现状态的转换，除此之外，我们还可以通过环境类来实现状态转换，环境类作为一个状态管理器，统一实现各种状态之间的转换操作。

      1. 在上述代码中，所有的状态转换操作都由环境类Screen来实现，此时，环境类充当了状态管理器角色。如果需要增加新的状态，例如“八倍状态类”，需要修改环境类，这在一定程度上违背了“开闭原则”，但对其他状态类没有任何影响。
6. 不使用状态模式的情况
7.  分析上述代码，我们不难发现存在如下几个问题：

          (1) 几乎每个方法中都包含状态判断语句，以判断在该状态下是否具有该方法以及在特定状态下该方法如何实现，导致代码非常冗长，可维护性较差；

          (2) 拥有一个较为复杂的stateCheck()方法，包含大量的if…else if…else…语句用于进行状态转换，代码测试难度较大，且不易于维护；

          (3) 系统扩展性较差，如果需要增加一种新的状态，如冻结状态（Frozen State，在该状态下既不允许存款也不允许取款），需要对原有代码进行大量修改，扩展起来非常麻烦。

8. 主要优点

          状态模式的主要优点如下：

          (1) 封装了状态的转换规则，在状态模式中可以将状态的转换代码封装在环境类或者具体状态类中，可以对状态转换代码进行集中管理，而不是分散在一个个业务方法中。

          (2) 将所有与某个状态有关的行为放到一个类中，只需要注入一个不同的状态对象即可使环境对象拥有不同的行为。

          (3) 允许状态转换逻辑与状态对象合成一体，而不是提供一个巨大的条件语句块，状态模式可以让我们避免使用庞大的条件语句来将业务方法和状态转换代码交织在一起。

          (4) 可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数。

9. 主要缺点

          状态模式的主要缺点如下：

          (1) 状态模式的使用必然会增加系统中类和对象的个数，导致系统运行开销增大。

          (2) 状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱，增加系统设计的难度。

          (3) 状态模式对“开闭原则”的支持并不太好，增加新的状态类需要修改那些负责状态转换的源代码，否则无法转换到新增状态；而且修改某个状态类的行为也需修改对应类的源代码。

10. 适用场景

          在以下情况下可以考虑使用状态模式：

          (1) 对象的行为依赖于它的状态（如某些属性值），状态的改变将导致行为的变化。

          (2) 在代码中包含大量与对象状态有关的条件语句，这些条件语句的出现，会导致代码的可维护性和灵活性变差，不能方便地增加和删除状态，并且导致客户类与类库之间的耦合增强。

11. 参考 https://blog.csdn.net/csdn_ds/article/details/78723782