35.1 迷你版的交易系统

介绍，有兴趣的读者可以看看MQ的资料。我们在这里的讲解实现的是一个快乐路径，认为所有的交易都是在安全可靠的环境中发生的，并且所有的系统环境都满足我们的要求。我们再来看另一个策略，这个策略更简单，如代码清单35-5所示。

代码清单35-5 扣款策略二

public class FreeDeduction implements IDeduction {

//自由扣款

public boolean exec(Card card, Trade trade) {

//直接从自由余额中扣除

card.setFreeMoney(card.getFreeMoney() - trade.getAmount());

return true;

卡内的自由金额减去交易金额再修改卡内自由金额就完事了，异常情况不考虑。这两个具体的策略与我们的交易类型没有任何关系，也不应该有关系，策略模式就是提供两个可以相互替换的策略，至于在什么时候使用什么策略，则不是由策略模式来决定的。策略模式还有一个角色没出场，即封装角色，如代码清单35-6所示。

代码清单35-6 扣款策略的封装

public class DeductionContext {

//扣款策略

private IDeduction deduction = null;

//构造函数传递策略

public DeductionContext(IDeduction _deduction) {

this.deduction = _deduction;

//执行扣款

public boolean exec(Card card,Trade trade) {

return this.deduction.exec(card, trade);

典型的策略上下文角色。扣款模块的策略已经定义完毕了，然后需要想办法解决策略模式的缺陷：它把所有的策略类都暴露出去，暴露得越多以后的修改风险也就越大。怎么修改呢？增加一个映射配置文件，实现策略类的隐藏。我们使用枚举担当此任，对策略类进行映射处理，避免高层模块直接访问策略类，同时由工厂方法模式根据映射产生策略对象，类图如图35-3所示。

图35-3 策略工厂类图

又是一个简单得不能再简单的模式——工厂方法模式，通过StrategyMan负责对具体策略的映射，如代码清单35-7所示。

代码清单35-7 策略枚举

public enum StrategyMan {

SteadyDeduction("com.cbf4life.common.SteadyDeduction"),FreeDeduction("com.cbf4life.common.FreeDeduction");

String value = "";

private StrategyMan(String _value) {

this.value = _value;

public String getValue() {

return this.value;

类似的代码解释过很多遍了，不再多说，它就是一个登记容器，所有的具体策略都在这里登记，然后提供给工厂方法模式。策略工厂如代码清单35-8所示。

代码清单35-8 策略工厂

public class StrategyFactory {

//策略工厂

public static IDeduction getDeduction(StrategyMan strategy) {

IDeduction deduction = null;

try {

deduction = (IDeduction)Class.forName(strategy.getValue()).newInstance();

catch (Exception e) {

// 异常处理

return deduction;

一个简单的工厂，根据策略管理类的枚举项创建一个策略对象，简单而实用，策略模式的缺陷也弥补成功。那这么复杂的系统怎么让高层模块访问？（你看不出复杂？那是因为我们写的都是快乐路径，太多情况都没有考虑，在实际项目中仅就并发处理和事务管理这两部分就够你头疼了。）既然系统很复杂，是不是需要封装一下。我们请出门面模式进行封装，如代码清单35-9所示。

代码清单35-9 扣款模块封装

public class DeductionFacade {

//对外公布的扣款信息

public static Card deduct(Card card,Trade trade) {

//获得消费策略

StrategyMan reg = getDeductionType(trade);

//初始化一个消费策略对象

IDeduction deduction = StrategyFactory.