1700482315
1700482316
public static Card deduct（Card card,Trade trade）{
1700482317
1700482318
//获得消费策略
1700482319
1700482320
StrategyMan reg=getDeductionType（trade）；
1700482321
1700482322
//初始化一个消费策略对象
1700482323
1700482324
IDeduction deduction=StrategyFactory.getDeduction（reg）；
1700482325
1700482326
//产生一个策略上下文
1700482327
1700482328
DeductionContext context=new DeductionContext（deduction）；
1700482329
1700482330
//进行扣款处理
1700482331
1700482332
context.exec（card,trade）；
1700482333
1700482334
//返回扣款处理完毕后的数据
1700482335
1700482336
return card；
1700482337
1700482338
}
1700482339
1700482340
//获得对应的商户消费策略
1700482341
1700482342
private static StrategyMan getDeductionType（Trade trade）{
1700482343
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所示。
[
上一页 ]
[ :1.700482315e+09 ]
[
下一页 ]