这是一个糖果机的需求图.
它有四种状态, 分别是图中的四个圆圈:
No Quarter: 无硬币
Has Quater 有硬币
Gumball Sold 糖果卖出
Out of Gumball 没有糖果了
这个图很像一个状态图. 每个圆圈就是一个状态, 每个带箭头的线就是状态的转换.
这个需求用文字描述就是: 糖果机在没投硬币的时候, 可以投硬币, 投完硬币, 搬动手柄, 糖果就会出来, 如果糖果机里没有糖果了, 那么就无法再卖糖果了.
初步设计这个需求看起来还是蛮简单的, 我想可以这样来实现:
1. 整理好所有的状态, 一共有4个:
2. 创建一个实例变量来保存当前的状态, 并为每个状态定义一个值:
3. 整理好系统中可能发生的动作:
4. 创建一个类作为状态机, 针对每一个动作, 我们创建一个方法, 在方法里我们使用条件语句来决定在每个状态中该行为是否合理. 例如, 投入硬币后, 我们可能需要下面这个方法:
注意: 最后一个if中, 有改变状态的动作(如果之前的状态是没有硬币, 那么投入硬币后, 状态应改为有硬币).
下面来实现这个状态机:
代码量还是不小啊, 这里面主要做的就是在每个动作方法里, 判断各种状态, 如何合理就改变状态.
运行一下:
结果:
看起来一切都OK了, 直到:
需求变更糖果机老板说, 我想买糖果变成一个游戏, 投硬币买糖果的人中的10%在搬动手柄后将会得到两个糖果而不是一个.
现在的状态开始有点乱了:
随着需求的变化, 我们设计会导致越来越多的bug...
回想一下设计原则: "把变化的部分封装起来" 和 "尽量使用组合". 我们可以把每个状态的行为放到它自己的类里面, 然后每个动作只需要实现自己状态下的动作即可. 而且也许糖果机可以使用状态对象来委托表示自己当前的状态.
重新设计这次我们就把状态的行为封装到各个状态对象里面, 并在动作发生的时候委托到当前的状态.
1. 首先, 定义一个状态接口, 这个接口包含糖果机的每个动作
2. 针对每种状态, 实现一个具体的状态类. 这些类将负责糖果机在改状态下的行为.
3. 最后, 去掉那些条件判断代码, 把这些工作委托给状态类.
上面要实现的就是状态模式 (State Pattern).
把一个状态所有的行为放到一个类里面, 这样, 就实现了本地化并且便于修改和理解.
设计类图: