Design Pattern Note-State Pattern

一. 定义

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

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

模式结构 :

状态模式包含如下角色:

  1. Context: 上下文类

    环境类又称为上下文类,它是拥有多种状态的对象。由于环境类的状态存在多样性且在不同状态下对象的行为有所不同,因此将状态独立出去形成单独的状态类。在环境类中维护一个抽象状态类State的实例,这个实例定义当前状态,在具体实现时,它是一个State子类的对象。

  2. State: 抽象状态类

    它用于定义一个接口以封装与环境类的一个特定状态相关的行为,在抽象状态类中声明了各种不同状态对应的方法,而在其子类中实现类这些方法,由于不同状态下对象的行为可能不同,因此在不同子类中方法的实现可能存在不同,相同的方法可以写在抽象状态类中。

  3. ConcreteState: 具体状态类

    它是抽象状态类的子类,每一个子类实现一个与环境类的一个状态相关的行为,每一个具体状态类对应环境的一个具体状态,不同的具体状态类其行为有所不同。

二. 常用场景

在以下情况下可以使用状态模式:

  1. 对象的行为依赖于它的状态(属性)并且可以根据它的状态改变而改变它的相关行为。
  2. 代码中包含大量与对象状态有关的条件语句,这些条件语句的出现,会导致代码的可维护性和灵活性变差,不能方便地增加和删除状态,使客户类与类库之间的耦合增强。在这些条件语句中包含了对象的行为,而且这些条件对应于对象的各种状态。

主要应用场景:

  1. 如果项目中存在太多的 if {…} elseif {…} else {…} 。那么你应该考虑状态模式。我觉得这个是重点考虑对象
  2. 如果每个状态中处理的业务逻辑特别复杂·那么建议考虑这种方式
  3. spring中单独实现了一个状态机:https://projects.spring.io/spring-statemachine/

三. 优缺点

优点

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

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

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

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

    缺点

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

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

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

参考文献

  1. 设计模式(行为型)之状态模式(State Pattern)
  2. php设计模式:状态模式的使用场景