1700473923
1700473924
设计模式之禅 26.3.3 状态模式的使用场景
1700473925
1700473926
❑行为随状态改变而改变的场景
1700473927
1700473928
这也是状态模式的根本出发点，例如权限设计，人员的状态不同即使执行相同的行为结果也会不同，在这种情况下需要考虑使用状态模式。
1700473929
1700473930
❑条件、分支判断语句的替代者
1700473931
1700473932
在程序中大量使用switch语句或者if判断语句会导致程序结构不清晰，逻辑混乱，使用状态模式可以很好地避免这一问题，它通过扩展子类实现了条件的判断处理。
1700473933
1700473934
1700473935
1700473936
1700473937
设计模式之禅 26.3.4 状态模式的注意事项
1700473938
1700473939
状态模式适用于当某个对象在它的状态发生改变时，它的行为也随着发生比较大的变化，也就是说在行为受状态约束的情况下可以使用状态模式，而且使用时对象的状态最好不要超过5个。
1700473940
1700473941
1700473942
1700473943
1700473944
设计模式之禅 [:1700454046]
1700473945
设计模式之禅 26.4 最佳实践
1700473946
1700473947
上面的例子可能比较复杂，请各位看官耐心看，看完肯定有所收获。我翻遍了所有能找得到的资料（关于这个电梯的例子也是由《Design Pattern for Dummies》这本书激发出来的），基本上没有一本把这个状态模式讲透彻的（当然，还是有几本讲得不错），我不敢说我就讲得透彻，大家都只讲了一个状态到另一个状态的过渡。状态间的过渡是固定的，举个简单的例子，如图26-6所示。
1700473948
1700473949
1700473950
1700473951
1700473952
图26-6 简单状态切换示意图
1700473953
1700473954
这个状态图是很多书上都有的，状态A只能切换到状态B，状态B再切换到状态C。举例最多的就是TCP监听的例子。TCP有3个状态：等待状态、连接状态、断开状态，然后这3个状态按照顺序循环切换。按照这个状态变更来讲解状态模式，我认为是不太合适的，为什么呢？你在项目中很少看到一个状态只能过渡到另一个状态情形，项目中遇到的大多数情况都是一个状态可以转换为几种状态，如图26-7所示。
1700473955
1700473956
1700473957
1700473958
1700473959
图26-7 复杂状态切换示意图
1700473960
1700473961
状态B既可以切换到状态C，又可以切换到状态D，而状态D也可以切换到状态A或状态B，这在项目分析过程中有一个状态图可以完整地展示这种蜘蛛网结构，例如，一些收费网站的用户就有很多状态，如普通用户、普通会员、VIP会员、白金级用户等，这个状态的变更你不允许跳跃？！这不可能，所以我在例子中就举了一个比较复杂的应用，基本上可以实现状态间自由切换，这才是最经常用到的状态模式。
1700473962
1700473963
再提一个问题，状态间的自由切换，那会有很多种呀，你要挨个去牢记一遍吗？比如上面那个电梯的例子，我要一个正常的电梯运行逻辑，规则是开门-＞关门-＞运行-＞停止；还要一个紧急状态（如火灾）下的运行逻辑，关门-＞停止，紧急状态时，电梯当然不能用了；再要一个维修状态下的运行逻辑，这个状态任何情况都可以，开着门电梯运行？可以！门来回开关？可以！永久停止不动？可以！那这怎么实现呢？需要我们把已经有的几种状态按照一定的顺序再重新组装一下，那这个是什么模式？什么模式？大声点！建造者模式！对，建造模式+状态模式会起到非常好的封装作用。
1700473964
1700473965
更进一步，应该有部分读者做过工作流开发，如果不是土制框架，那么就应该有个状态机管理（即使是土制框架也应该有），如一个Activity（节点）有初始化状态（Initialized State）、挂起状态（Suspended State）、完成状态（Completed State）等，流程实例也有这么多状态，那这些状态怎么管理呢？通过状态机（State Machine）来管理，那状态机是个什么东西呢？就是我们上面提到的Context类的升级变态BOSS！
1700473966
1700473967
1700473968
1700473969
1700473970
设计模式之禅 [:1700454047]
1700473971
设计模式之禅 第27章 解释器模式
1700473972