设计模式笔记 - 状态模式(State Pattern)
设计模式笔记 - 状态模式(State Pattern)
模式定义
状态模式(State Pattern)允许一个对象在其内部状态改变时改变它的行为,对象看起来似乎修改了它的类。状态模式是一种对象行为型模式。
模式结构
状态模式包含如下角色:
- Context - 环境类
- State - 抽象状态类
- ConcreteState - 具体状态类
模式实例
1 | /* |
模式分析
- 状态模式描述了对象状态的变化,以及对象如何在每一种状态下表现出不同的行为。
- 状态模式的关键是导入了一个抽象类来专门表示对象的状态,这个类我们叫做抽象状态类,而对象的每一种具体状态类都继承了该类,并在不同的具体状态类中实现了不同状态的行为,包括各种状态之间的转换。
在状态模式结构中需要理解环境类与抽象状态类的作用:
- 环境类 - 实际上就是拥有状态的对象,环境类有时候可以充当状态管理器(State Manager)的角色,可以在环境类中对状态进行切换操作。
- 抽象状态类 - 可以是抽象类,也可以是接口,不同状态类就是继承这个父类的不同子类,状态类的产生是由于环境类存在多个状态,同时还满足两个条件:一是这些状态经常需要切换,二是在不同状态下对象的行为不同。因此可以将不同对象下的行为单独提取出来封装在具体的状态类中,使得环境类对象在其内部状态改变时可以改变它的行为,让对象看起来似乎修改了它的类,而实际上是由于切换到不同的具体状态类实现的。
状态模式的优点:
- 封装了转换规则。
- 将所有与某个状态有关的行为放到同一个类中,并且方便地添加新的状态,只需改变对象状态,即可改变对象的行为。
- 允许状态转换逻辑与状态对象合为一体,舍弃巨大的逻辑条件块(if..else..)
- 可以让多个环境对象共享一个状态对象,从而减少系统中对象的个数。
状态模式的缺点:
- 状态模式的使用必然会增加系统类和对象的个数。
- 状态模式的结构与实现都较为复杂,如果使用不当将导致程序结构和代码的混乱。
- 状态模式对“开闭原则”的支持并不太好,对于可以切换状态的状态模式,增加新的状态类需要修改那些负责状态转换的源代码,否则无法切换到新增状态;而且修改某个状态类的行为也需修改对应类的源代码。
模式应用
- 状态模式在工作流或游戏等类型的软件中得以广泛使用,甚至可以用于这些系统的核心功能设计,如在政府OA办公系统中,一个批文的状态有多种:尚未办理,正在办理,正在批示,正在审核,已经完成等各种状态,而且批文状态不同时对批文的操作也有所差异。使用状态模式可以描述工作流对象(如批文)的状态转换以及不同状态下它所具有的行为。
模式扩展
共享状态
- 在有些情况下多个环境对象需要共享同一个状态,如果希望在系统中实现多个环境对象实例共享一个或多个状态对象,那么需要将这些状态对象定义为环境的静态成员对象。
参考资料:
[1] https://design-patterns.readthedocs.io/zh_CN/latest/behavioral_patterns/state.html