首页 » 设计模式之禅(第2版) » 设计模式之禅(第2版)全文在线阅读

《设计模式之禅(第2版)》26.3 状态模式的应用

关灯直达底部

26.3.1 状态模式的优点

● 结构清晰

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

● 遵循设计原则

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

● 封装性非常好

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

26.3.2 状态模式的缺点

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

26.3.3 状态模式的使用场景

● 行为随状态改变而改变的场景

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

● 条件、分支判断语句的替代者

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

26.3.4 状态模式的注意事项

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

26.4 最佳实践

上面的例子可能比较复杂,请各位看官耐心看,看完肯定有所收获。我翻遍了所有能找得到的资料(关于这个电梯的例子也是由《Design Pattern for Dummies》这本书激发出来的),基本上没有一本把这个状态模式讲透彻的(当然,还是有几本讲得不错),我不敢说我就讲得透彻,大家都只讲了一个状态到另一个状态的过渡。状态间的过渡是固定的,举个简单的例子,如图26-6所示。

图26-6 简单状态切换示意图

这个状态图是很多书上都有的,状态A只能切换到状态B,状态B再切换到状态C。举例最多的就是TCP监听的例子。TCP有3个状态:等待状态、连接状态、断开状态,然后这3个状态按照顺序循环切换。按照这个状态变更来讲解状态模式,我认为是不太合适的,为什么呢?你在项目中很少看到一个状态只能过渡到另一个状态情形,项目中遇到的大多数情况都是一个状态可以转换为几种状态,如图26-7所示。

图26-7 复杂状态切换示意图

状态B既可以切换到状态C,又可以切换到状态D,而状态D也可以切换到状态A或状态B,这在项目分析过程中有一个状态图可以完整地展示这种蜘蛛网结构,例如,一些收费网站的用户就有很多状态,如普通用户、普通会员、VIP会员、白金级用户等,这个状态的变更你不允许跳跃?!这不可能,所以我在例子中就举了一个比较复杂的应用,基本上可以实现状态间自由切换,这才是最经常用到的状态模式。

再提一个问题,状态间的自由切换,那会有很多种呀,你要挨个去牢记一遍吗?比如上面那个电梯的例子,我要一个正常的电梯运行逻辑,规则是开门->关门->运行->停止;还要一个紧急状态(如火灾)下的运行逻辑,关门->停止,紧急状态时,电梯当然不能用了;再要一个维修状态下的运行逻辑,这个状态任何情况都可以,开着门电梯运行?可以!门来回开关?可以!永久停止不动?可以!那这怎么实现呢?需要我们把已经有的几种状态按照一定的顺序再重新组装一下,那这个是什么模式?什么模式?大声点!建造者模式!对,建造模式+状态模式会起到非常好的封装作用。

更进一步,应该有部分读者做过工作流开发,如果不是土制框架,那么就应该有个状态机管理(即使是土制框架也应该有),如一个Activity(节点)有初始化状态(Initialized State)、挂起状态(Suspended State)、完成状态(Completed State)等,流程实例也有这么多状态,那这些状态怎么管理呢?通过状态机(State Machine)来管理,那状态机是个什么东西呢?就是我们上面提到的Context类的升级变态BOSS!