java设计模式--状态模式--04

 

一、定义：
1，状态模式允许一个"对象"在其内部状态改变的时候改变其行为。
2，状态模式的角色：
抽象状态，具体状态，环境(context)角色

适用场景：（两条件同时满足）
1.一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为。
2.一个操作中含有庞大的多分支结构，并且这些分支决定于对象的状态。

实际情况1：在一个业务逻辑――实现类里，一般都是一个函数里边写2000－3000行代码，并且伴有大量的分支语句，这样的语句大多被用来判断提交了什么条件，然后处理的。特点为：if ...else if...else if ...。 需求不断变化，类似的分支语句还要不断扩展支持下去。场景特征：如果分支条件改变时， 改变它的行为。

实际情况2：有点类似开关,开始是设置2个开关,来代表"开","关",发现浪费材料,可以用一个,上去代表"开",下来代表"关",于是扩展开来,多功能的都可以用一个实现,按一次是"冷风",再按"换气",再按"除湿"......一堆功能封装起来了.

用法：

好处"找出应用中需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起".业务逻辑类中，将判断分离出”业务逻辑实现类“中，简化其编码和功能。业务逻辑实现类，只是一个平台，提供管理业务逻辑中的动作，而不是具体的操作实现。

特点：
State模式允许一个对象基于内部状态而拥有不同的行为；
State模式允许使用类代表状态 ；
Context会将行为委托给当前对象；
通过将每个状态封装进一个类，我们把以后需要做的任何更改局部化了 ；
状态（state）的转换可以由StateHandler类或者context类来控制 ；
状态处理类（StateHandler）可以被多个Context实例共享。

缺点是： 使用状态模式将会导致设计中类的数目大量增加 。

 

需要注意的地方:
1. state之间的转换. State的转换可以在State类内部完成, 但是这样会带来的问题是各个State之间出现了关联, 那么如果一个State本身改变(减少, 增加) 会带来很大影响, 你就有可能看看当前发生改变的state是否也影响到了其它的state的执行. 不过经过跟同事的讨论发现也是在所难免的. 另外一个, state的转换也可以由其它类调用Context的setState()来完成, 感觉这种情况更不可靠, 因为这样的话其他类就必须知道context的特定state, 带来了不必要的耦合, 因此建议对setState()的调用尽量放在Context和State这两处.
2. State的创建和销毁. 两个方法: 1.在context内部创建所有state, 一直维护从不销毁.2.在状态转换的时候才创建, 然后上一个state由JVM自动回收. 主要原则需要看实际情况是Context的State的变化是否频繁, 如果不频繁, 建议用第二种,比较优雅.