1700482344
//模拟操作
1700482345
1700482346
if（trade.getTradeNo（）.contains（“abc”））{
1700482347
1700482348
return StrategyMan.FreeDeduction；
1700482349
1700482350
}else{
1700482351
1700482352
return StrategyMan.SteadyDeduction；
1700482353
1700482354
}
1700482355
1700482356
}
1700482357
1700482358
}
1700482359
1700482360
这次为什么要先展示代码而后写类图呢？那是因为这段代码比写类图更能让你理解。读者注意一下getDeductionType方法，这个方法在实际项目中是存在的，但是与上面的写法有天壤之别，因为在实际项目中，数据库中保存了策略代码与交易编码的对应关系，直接通过数据库的SQL语句就可以返回对应的扣款策略。这里我们采用大家最熟悉的条件转移来实现，也是比较清晰和容易理解的。
1700482361
1700482362
可能读者要问了，在门面模式中已经明确地说明，门面类中不允许有业务逻辑存在，但是你这里还是有了一个getDeductionType方法，它可代表的是一个判断逻辑呀，这是为什么呢？是的，该方法完全可以移到其他Hepler类中，由于我们是示例代码，暂没有明确的业务含义，故编写在此处，读者在实际应用中，请把该方法放置到其他类中。
1700482363
1700482364
好，所有用到的模式都介绍完毕了，我们把完整的类图整理一下，如图35-4所示。
1700482365
1700482366
1700482367
1700482368
1700482369
图35-4 扣款子模块完整类图
1700482370
1700482371
真实系统比这复杂得多，有了我们之前的分析，这个图还是比较容易看懂的。我们所有的开发都完成了，是不是应该写一个测试类来展示一下我们的成果，如代码清单35-10所示。
1700482372
1700482373
代码清单35-10 场景类
1700482374
1700482375
public class Client{
1700482376
1700482377
//模拟交易
1700482378
1700482379
public static void main（String[]args）{
1700482380
1700482381
//初始化一张IC卡
1700482382
1700482383
Card card=initIC（）；
1700482384
1700482385
//显示一下卡内信息
1700482386
1700482387
System.out.println（”========初始卡信息：=========”）；
1700482388
1700482389
showCard（card）；
1700482390
1700482391
//是否停止运行标志
1700482392
1700482393
boolean flag=true；