某项目中在业务逻辑的处理过程中需要处理多种的中断信号，导致逻辑部分的代码被搞得支离破碎。一直在想有没有好点的，漂亮一点的方法。这次在一个后续的项目中真好有一个重写这部分代码的机会，就拿它开开刀，拉出来练练。
1．分离逻辑处理和中断处理
在原来的实现中因为没有区分处理的原有逻辑和中断逻辑，才导致到处都是大段大段的if/else的。所以上来就将处理逻辑和中断逻辑砍开：
・处理逻辑：在理想状态下的处理逻辑，针对指定信息源作解析处理。
・中断逻辑：针对特殊事件，每个部件所需要采取的处理。
2．抽出处理逻辑中状态
分离出中断逻辑就简单了，很容易的就发现原有的系统中复杂的原因所在，需要在逻辑处理的不同状态下，处理各种中断。
分析各种逻辑，最后得出三种状态机模型：
・一状态状态机：它只有一个状态，只有一个状态那不是什么判断都没有。它其实是只响应中断的处理。
・两状态状态机：它有两个状态，可以描述基于一个阈值的判断。也可以说成“只要那个啥，啥啥了，就啥啥啥。”。
・三状态状态机：它有三个状态，可以描述基于两个阈值的判断。也可以说成“只要那个啥1，啥啥1了，再那个啥2，也啥啥2了，就啥啥啥。”。
啥多了不行，还得整点图。
2.1 一状态的状态机
确实啥也不干，就指望着中断来点啥了。
2.2 两状态状态机
这个好点，判断一个阈值就行了。
2.3 三状态状态机
两个阈值的判断。
也不咋地啊，最多也就2个条件，3个状态，4个中断，其实也就12种状态，但是硬是差点没搞明白。
3．实现
模型出来了，抽一下共同就变成下面这个样了
两个接口：
・Interruptable：封装各种中断的入口
・Logic：封装逻辑的接口，包含中断接口
状态机的实现：
・State：描述各个状态，并提供此状态下的中断接口
・StateMachine：封装状态迁移的逻辑，开放各种状态迁移时的接口。所有中断直接扔给当前状态。
下面是各个模型的共同化
・一状态状态机就一个实现没共同化
・LogicWitch2State：封装了2个状态，并提供各个业务的接口。
・LogicWitch3State：封装了3个状态，并提供各个业务的接口。
再下面就是各个具体的实现了
4．总结
搞完了就想，图个啥啦？本来直接实现就行了，这么一整就活活多出来2个接口和4各类。整地呼哧呼哧的,图啥啦？
想来想去也就图个容易理解。虽然咱IT这行主要是为了让计算机帮咱们干点活，只要计算机明白了其实也就行了。但是在现实中，客户都是善变的，往往一个东西总是要翻来覆去的修改，还经常换着人去改。如果人不容易理解，就计算机明白的话，那后来的人也还要再痛苦一遍。而搞个好点的模式就方便了，容易懂，容易讲，忘了再看一下就明白了。