1700482576
1700482577
1001交易成功！
1700482578
1700482579
本次发生的交易金额为：12.34元
1700482580
1700482581
IC卡编号：1100010001000
1700482582
1700482583
固定类型余额：793.83元
1700482584
1700482585
自由类型余额：893.83元
1700482586
1700482587
是否需要退出？（Y/N）
1700482588
1700482589
交易成功！到这里为止，联机交易中的扣款子模块开发完毕了！是不是很简单，银行业的交易系统也就是这么回事！
1700482590
1700482591
1700482592
1700482593
1700482595
设计模式之禅 35.2 混编小结
1700482596
1700482597
回顾一下我们在该案例中使用了几个模式。
1700482598
1700482599
❑策略模式
1700482600
1700482601
负责对扣款策略进行封装，保证两个策略可以自由切换，而且日后增加扣款策略也非常简单容易。
1700482602
1700482603
❑工厂方法模式
1700482604
1700482605
修正策略模式必须对外暴露具体策略的问题，由工厂方法模式直接产生一个具体策略对象，而其他模块则不需要依赖具体的策略。
1700482606
1700482607
❑门面模式
1700482608
1700482609
负责对复杂的扣款系统进行封装，封装的结果就是避免高层模块深入子系统内部，同时提供系统的高内聚、低耦合的特性。
1700482610
1700482611
我们主要使用了这三个模式，它们的好处是灵活、稳定，我们可以设想一下可能有哪些业务变化。
1700482612
1700482613
❑扣款策略变更
1700482614
1700482615
增加一个新扣款策略，三步就可以完成：实现IDeduction接口，增加StrategyMan配置项，扩展扣款策略的利用（也就是门面模式的getDeductionType方法，在实际项目中这里只需要增加数据库的配置项）。减少一个策略很简单，修改扣款策略的利用即可。变更一个扣款策略也很简单，扩展一个实现类口就可以了。
1700482616
1700482617
❑变更扣款策略的利用规则
1700482618
1700482619
我们的系统不想大修改，还记得我们提出的状态模式吗？这个就是为策略的利用服务的，变更它就能满足要求。想把IC卡也纳入策略利用的规则也不复杂。其实这个变更还真发生了，系统投产后，业务提出考虑退休人员的情况，退休人员的IC卡与普通在职员工一样，但是它的扣款不仅仅是根据交易编码，还要根据IC卡对象，系统的变更做法是增加一个扣款策略，同时扩展扣款利用策略，也就是数据库的配置项，在getDeductionType中新扩展了一个功能：根据IC卡号，确认是否是退休人员，是退休人员，则使用新的扣款策略，这是一个非常简单的扩展。
1700482620
1700482621
这就是一个mini版的金融交易系统，没啥复杂的，剩下的问题就是开始考虑系统的鲁棒性，这才是难点。
1700482622
1700482623
1700482624
1700482625
[
上一页 ]
[ :1.700482576e+09 ]
[
下一页 ]