1700482041
很明显，这是一个策略模式的实际应用，但是你还记得策略模式是有缺陷的吗？它的具体策略必须暴露出去，而且还要由上层模块初始化，这不合适，与迪米特法则有冲突，高层次模块对低层次的模块应该仅仅处在“接触”的层次上，而不应该是“耦合”的关系，否则，维护的工作量就会非常大。问题提出了，那我们就应该想办法来修改这个缺陷，正好工厂方法模式可以帮我们产生指定的对象，但是问题又来了，工厂方法模式要指定一个类，它才能产生对象，怎么办？引入一个配置文件进行映射，避免系统僵化情况的发生，我们以枚举类完成该任务。
1700482042
1700482043
还有一个问题，一个交易的扣款模式是固定的，根据其交易编号而定，那我们怎样把交易编号与扣款策略对应起来呢？采用状态模式或责任链模式都可以，如果采用状态则认为交易编号就是一个交易对象的状态，对于一笔确定的交易（一个已经生成了的对象），它的状态不会从一个状态过渡到另一个状态，也就是说它的状态只有一个，执行完毕后即结束，不存在多状态的问题；如果采用责任链模式，则可以用交易编码作为链中的判断依据，由每个执行节点进行判断，返回相应的扣款模式。但是在实际中，采用了关系型数据库存储扣款规则与交易编码的对应关系，为了简化该部分的讲义，我们在下面的设计中使用了条件判断语句来代替。
1700482044
1700482045
还有，这么复杂的扣款模块总要进行一个封装吧，不能让上层的业务模块直接深入到模块的内部，于是门面模式又摆在了眼前。
1700482046
1700482047
分析完毕，我们要先画出类图，做设计要遵循这样一个原则：先选最简单的业务，然后画出类图。那我们先定义交易中用到的两个类：IC卡类和交易类，如图35-1所示。
1700482048
1700482049
1700482050
1700482051
1700482052
图35-1 IC卡类和交易类
1700482053
1700482054
每个IC卡有三个属性，分别是IC卡号码、固定金额、自由金额，然后通过getter/setter方法来访问，如代码清单35-1所示。
1700482055
1700482056
代码清单35-1 IC卡类
1700482057
1700482058
public class Card{
1700482059
1700482060
//IC卡号码
1700482061
1700482062
private String cardNo=””；
1700482063
1700482064
//卡内的固定交易金额
1700482065
1700482066
private int steadyMoney=0；
1700482067
1700482068
//卡内自由交易金额
1700482069
1700482070
private int freeMoney=0；
1700482071
1700482072
//getter/setter方法
1700482073
1700482074
public String getCardNo（）{
1700482075
1700482076
return cardNo；
1700482077
1700482078
}
1700482079
1700482080
public void setCardNo（String cardNo）{
1700482081
1700482082
this.cardNo=cardNo；
1700482083
1700482084
}
1700482085
1700482086
public int getSteadyMoney（）{
1700482087
1700482088
return steadyMoney；
1700482089
1700482090
}