设计模式之“状态模式”
由来
最近的项目当中,需要添加新的功能来满足产品需求。因为我们的产品是一个特殊的器械,在机器运行的任何时刻,都可能会有人的操作和介入,所以之前的代码对于各种从外部进来的输入都是使用if else
的结构来解决。困难是随着功能的增加,这个if else
的代码块会越来越多,并且新的代码可能会把原来的功能破坏掉。为了解耦不同状态下的操作,并且让系统有正确的输出,我们决定重构这一部分的代码。
最近的体会
雷军作为中国最早的一批软件开发从业者,他曾经说过,在写代码的过程中,如果你认为某一个地方可能会出现错误,那么,那个地方就或多或少一定会出问题。这句话带给我的体会就是,软件设计的思路一定要非常清楚,功能之间耦合度降到最低,这样的代码才会拥有更高的品质。
状态模式
状态模式的设计思路很像有限状态机。在任何一个时刻,系统都处于某一种状态下,在这种状态下,系统拥有独特的行为。并且由于某种原因(可能是外部的输入或者系统运行到了某些条件)系统的当前状态会切换到其他的状态继续运行。这种切换是随时的,从用户的角度来看,只是行为发生了变换,但是软件的实现是通过不同的类(Status)来实现这些行为的。
具体实现
本文参考了两本书,一本是《Dive into Design Patterns》,另外一本是《Head First 设计模式》。
在下面的结构图当中,业务接口Context
并不直接实现自己的成员函数,而是通过调用State
对象的成员来完成。State
作为实际工作的对象ConcreteStates
的基类,提供了一切可能被Context
调用的接口。在ConcreteStates
内部,针对自己的状态特点,可以实现在不同接口调用下的系统行为,并且还可以直接操作Context
对象的指针,来实现状态的切换。
总结
- 状态模式最大的特点是用户所关心的对象(
Context
)的状态和行为随着时间推移发生变化并不是这个对象自己切换出来的,而是它所拥有的状态自己做出了响应和切换为下一个状态。而且状态自己在赋值新状态的时候,是调用Context
的方法获取的,获取到的这个新状态是在Context
创建的时候已经创建好的,只能在有限的几个状态下切换。 - 在设计状态的时候,每一种状态要保证相互独立,没有耦合,而且需要做一个默认状态,这个状态包含了所有没有考虑进去的情况,在这种情况下,做统一的安全处理。
设计模式之“状态模式”
https://warden2018.github.io/2024/07/23/2024-07-23-DesignPattern-StateMode/