回顾一下我们在该案例中使用了几个模式。
● 策略模式
负责对扣款策略进行封装，保证两个策略可以自由切换，而且日后增加扣款策略也非常简单容易。
● 工厂方法模式
修正策略模式必须对外暴露具体策略的问题，由工厂方法模式直接产生一个具体策略对象，而其他模块则不需要依赖具体的策略。
● 门面模式
负责对复杂的扣款系统进行封装，封装的结果就是避免高层模块深入子系统内部，同时提供系统的高内聚、低耦合的特性。
我们主要使用了这三个模式，它们的好处是灵活、稳定，我们可以设想一下可能有哪些业务变化。
● 扣款策略变更
增加一个新扣款策略，三步就可以完成：实现IDeduction接口，增加StrategyMan配置项，扩展扣款策略的利用（也就是门面模式的getDeductionType方法，在实际项目中这里只需要增加数据库的配置项）。减少一个策略很简单，修改扣款策略的利用即可。变更一个扣款策略也很简单，扩展一个实现类口就可以了。
● 变更扣款策略的利用规则
我们的系统不想大修改，还记得我们提出的状态模式吗？这个就是为策略的利用服务的，变更它就能满足要求。想把IC卡也纳入策略利用的规则也不复杂。其实这个变更还真发生了，系统投产后，业务提出考虑退休人员的情况，退休人员的IC卡与普通在职员工一样，但是它的扣款不仅仅是根据交易编码，还要根据IC卡对象，系统的变更做法是增加一个扣款策略，同时扩展扣款利用策略，也就是数据库的配置项，在getDeductionType中新扩展了一个功能：根据IC卡号，确认是否是退休人员，是退休人员，则使用新的扣款策略，这是一个非常简单的扩展。
这就是一个mini版的金融交易系统，没啥复杂的，剩下的问题就是开始考虑系统的鲁棒性，这才是难点。