《设计模式之禅》之状态模式

一、状态模式的定义

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

1.状态模式中的3个角色

(1)State–抽象状态角色
接口或抽象类,负责对象状态定义,并且封装环境角色以实现状态切换。

(2)ConcreteState–具体状态角色
每一个具体状态必须完成两个职责:本状态的行为管理以及趋向状态处理,通俗地讲,就是本状态下要做的事情,以及本状态如何过渡到其他状态。

(3)Context–环境角色
定义客户端需要的接口,并且负责状态的切换。

状态模式相对来说比较复杂,它提供了一种对物质运动的另一个观察视角,通过状态变更促使行为的变化,就类似水的状态变更一样,一碗水的初始状态是液态,通过加热转变为气态,状态的改变同时也引起体积的扩大,然后就产生了一个新的行为:鸣笛或顶起壶盖,瓦特就是这么发明蒸汽机的。

二、状态模式的应用

1.状态模式的优点

(1)结构清晰

避免过多的switch…case或者if..else语句的使用,避免了程序的复杂性,提高系统的可维护性。

(2)遵循设计原则

很好地体现了开闭原则和单一职责原则,每个状态都是一个子类,你要增加状态就要增加子类,你要修改状态,你只修改一个子类就可以了。

(3)封装性非常好

这也是状态模式的基本要求,状态变换放置到类的内部来实现,外部的调用不用知道类内部如何实现状态和行为的变换。

2.状态模式的缺点

子类会太多,也就是类膨胀。如果一个事物有很多个状态也不稀奇,如果完全使用状态模式就会有太多的子类,不好管理,这个需要大家在项目中自己衡量。其实有很多方式解决这个状态问题,如在数据库中建立一个状态表,然后根据状态执行相应的操作,这个也不复杂,看大家的习惯和嗜好。

3.状态模式的使用场景

(1)为随状态改变而改变的场景

这也是状态模式的根本出发点,例如权限设计,人员的状态不同即使执行下相同的行为结果也会不同,在这种情况下需要考虑使用状态模式。

(2)条件、分支判断语句的替代性

在程序中大量使用switch语句或者if判断语句会导致程序结构不清晰,逻辑混乱,使用状态模式可以很好地避免这一问题,它通过扩展子类实现了条件的判断处理。

4.状态模式的注意事项

状态模式适用于当某个对象在它的状态发生改变时,它的行为也随着发生比较大的变化,也就是说在行为受状态约束的情况下可以使用状态模式,而且使用时对象的状态最好不要超过5个。

三、最佳实践

如工作流开发,如果不是土制框架,那么就应该有个状态机管理(即使是土制框架也应该有),如一个Activity(节点)有初始化状态(Initialized State)、挂起状态(Suspended State)、完成状态(Completed State)等,流程实例也有这么多状态,那这些状态怎么管理呢?通过状态机来管理。
代码示例地址如下:
https://github.com/developers-youcong/DesignPatternPractice/tree/master/State

文章目录
  1. 1. 一、状态模式的定义
    1. 1.1. 1.状态模式中的3个角色
  2. 2. 二、状态模式的应用
    1. 2.1. 1.状态模式的优点
      1. 2.1.1. (1)结构清晰
      2. 2.1.2. (2)遵循设计原则
      3. 2.1.3. (3)封装性非常好
    2. 2.2. 2.状态模式的缺点
    3. 2.3. 3.状态模式的使用场景
      1. 2.3.1. (1)为随状态改变而改变的场景
      2. 2.3.2. (2)条件、分支判断语句的替代性
    4. 2.4. 4.状态模式的注意事项
  3. 3. 三、最佳实践