1700482170
1700482171
public boolean exec（Card card,Trade trade）；
1700482172
1700482173
}
1700482174
1700482175
固定扣款的规则是固定金额和自由金额各扣除交易金额的一半，如代码清单35-4所示。
1700482176
1700482177
代码清单35-4 扣款策略一
1700482178
1700482179
public class SteadyDeduction implements IDeduction{
1700482180
1700482181
//固定性交易扣款
1700482182
1700482183
public boolean exec（Card card,Trade trade）{
1700482184
1700482185
//固定金额和自由金额各扣除50%
1700482186
1700482187
int halfMoney=（int）Math.rint（trade.getAmount（）/2.0）；
1700482188
1700482189
card.setFreeMoney（card.getFreeMoney（）-halfMoney）；
1700482190
1700482191
card.setSteadyMoney（card.getSteadyMoney（）-halfMoney）；
1700482192
1700482193
return true；
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所示。
[
上一页 ]
[ :1.70048217e+09 ]
[
下一页 ]