混编小结
我们回顾一下，我们在该案例中使用了几个模式：
1.策略模式
负责对扣款策略进行封装，保证两个策略是可以自由切换的，而且日后增加扣款策略也是非常简单容易的。
2. 工厂方法模式
修正策略模式必须对外暴露具体策略的问题，由工厂方法模式直接产生一个具体策略对象，而其他模块则不需要依赖具体的策略。
3.门面模式
负责对复杂的扣款系统进行封装，封装的结果就是避免高层模块深入子系统内部，同时提供系统的高内聚、低耦合的特性。
我们主要使用了这三个模式，好处是什么呢?灵活，稳定，我们可以设想一下，可能有哪些业务变化?
4.扣款策略变更
这个没问题，增加一个新扣款策略，三步就可以完成：实现IDeduction接口，增加StrategyMan配置项，扩展扣款策略的利用(也就是门面模式的的getDeductionType方法，在实际的项目中这里只需要增加数据库的配置项)，那减少一个策略呢?简单，修改扣款策略的利用，那变更一个扣款策略呢?也简单，扩展一个实现类口可以了。
5.变更扣款策略的利用规则
也简单，我们的系统不想大修改，还记得我们提出的状态模式吗?这个就是为策略的利用服务的，变更它就能满足你的要求，想把IC卡也纳入策略利用的规则，也简单，不复杂。其实这个变更还真发生了，系统投产后，业务提出考虑退休人员的情况，退休人员的IC卡与普通在职员工一样，但是它的扣款不仅仅是根据交易编码，还要根据IC卡对象，系统的变更做法是增加一个扣款策略，同时扩展扣款利用策略，也就是数据库的配置项，在getDeductionType中新扩展了一个功能：根据IC卡号，确认是否是退休人员，是退休人员，则使用新的扣款策略，非常简单的扩展。
这就是一个mini版的金融交易系统，没啥复杂的，剩下的问题就开始考虑系统的鲁棒性吧，这才是难点。在项目中快乐路径是最容易实现的，一旦融入悲伤路径，系统的复杂性就大大提高，所以呀，才有需求分析时要先要描述一个成功场景，然后再一步一步地增加扩展场景的迭代分析模式，否则一上来就考虑一堆的扩展场景，这会让你思维混乱、手足无措，直接进入郁闷假死状态。
