23种设计模式之状态模式
状态模式的定义
定义: 当一个对象内在状态改变时允许其改变行为, 这个对象看起来像改变了其类
通俗的说, 就是一个事物有不同的状态,在不同状态下执行各个方法时有不同的表现, 将每个状态都封装成一个类, 然后通过上下文对象统一管理
其类图如下:
其中的三个角色如下:
- State 抽象状态角色: 接口或抽象类, 负责对象状态定义, 并且封装环境角色以实现状态切换
- ConcreteState 具体状态角色: 每一个具体状态必须完成两个职责: 本状态的行为管理以及趋向状态处理, 通俗的说, 就是本状态下要做的事情, 以及本状态如何过渡到其他状态
- Context 环境角色: 定义客户端需要的接口, 并且负责具体状态的切换
抽象状态角色代码:
抽象状态中声明一个环境角色, 提供各个状态类自行访问, 并且提供所有状态的抽象行为, 由各个实现类实现
具体状态角色代码:
具体状态角色有两个职责: 处理本状态要完成的任务, 决定是否可以过度到其他状态.
环境角色代码:
环境角色有两个不成文的约束:
- 把状态对象生命为静态常量, 有几个状态对象就声明ji'ge几个静态常量
- 环境角色具有状态抽象角色定义的所有行为, 具体执行使用委托方式
场景类代码:
这样就实现了在不同状态下的切换
状态模式的应用
状态模式的优点:
- 结构清晰. 避免了过多的 switch...case 或者 if...else 语句的使用, 避免了程序的复杂性, 提高系统的可维护性
- 遵循设计原则. 很好的体现了开闭原则和单一职责原则, 眉哥哥状态都是一个子类, 你要增加状态就要增加子类, 要修改状态, 只修改一个子类即可
- 封装性非常好. 这也是状态模式的基本要求, 状态变换放置到类的内部来实现, 外部的调用不用知道类内部如何实现状态和行为的变换
状态模式的缺点:
状态模式只有一个 缺点, 子类会太多, 也就是类膨胀. 一个事物有很多个状态也不稀奇, 如果完全使用状态模式就会有太多的子类, 不好管理. 其实有很多方式可以解决这个状态问题, 如在数据库中建立一个状态表, 然后根据状态执行相应的操作.
状态模式的使用场景:
- 行为随状态改变 而改变的场景.
- 条件、分支判断语句的替代者. 在程序中大量使用 seitch 语句或者if 判断语句会导致程序结构不清晰, 逻辑混乱, 使用状态模式可以很好的避免这一问题, 它通过扩展子类实现了条件的判断处理
状态模式适用于当某个对象在它的状态发生改变时, 他的行为也随着发生比较大的变化, 也就是说在行为受状态约束的情况下可以使用状态模式, 而且使用时对象的状态最好不要超过5个
