1700482194
1700482195
}
1700482196
1700482197
}
1700482198
1700482199
这个具体策略也非常简单，就是两个金额各自减去交易额的一半（注意除数是2.0，可不是2），然后再四舍五入，算法确实简单。该逻辑没有考虑账户余额不足的情况，也没有考虑异常情况，比如并发情况，读者可以想想看，一张卡有两笔消费同时发生时，是不是就发生错误了？一张卡同时有两笔消费会出现这种情况吗？会的，网络阻塞的情况，MQ多通道发送，在网络繁忙的情况下是有可能出现该问题，这里就不多介绍，有兴趣的读者可以看看MQ的资料。我们在这里的讲解实现的是一个快乐路径，认为所有的交易都是在安全可靠的环境中发生的，并且所有的系统环境都满足我们的要求。我们再来看另一个策略，这个策略更简单，如代码清单35-5所示。
1700482200
1700482201
代码清单35-5 扣款策略二
1700482202
1700482203
public class FreeDeduction implements IDeduction{
1700482204
1700482205
//自由扣款
1700482206
1700482207
public boolean exec（Card card,Trade trade）{
1700482208
1700482209
//直接从自由余额中扣除
1700482210
1700482211
card.setFreeMoney（card.getFreeMoney（）-trade.getAmount（））；
1700482212
1700482213
return true；
1700482214
1700482215
}
1700482216
1700482217
}
1700482218
1700482219
卡内的自由金额减去交易金额再修改卡内自由金额就完事了，异常情况不考虑。这两个具体的策略与我们的交易类型没有任何关系，也不应该有关系，策略模式就是提供两个可以相互替换的策略，至于在什么时候使用什么策略，则不是由策略模式来决定的。策略模式还有一个角色没出场，即封装角色，如代码清单35-6所示。
1700482220
1700482221
代码清单35-6 扣款策略的封装
1700482222
1700482223
public class DeductionContext{
1700482224
1700482225
//扣款策略
1700482226
1700482227
private IDeduction deduction=null；
1700482228
1700482229
//构造函数传递策略
1700482230
1700482231
public DeductionContext（IDeduction_deduction）{
1700482232
1700482233
this.deduction=_deduction；
1700482234
1700482235
}
1700482236
1700482237
//执行扣款
1700482238
1700482239
public boolean exec（Card card,Trade trade）{
1700482240
1700482241
return this.deduction.exec（card,trade）；
1700482242
1700482243
}
[
上一页 ]
[ :1.700482194e+09 ]
[
下一页 ]