工厂方法模式+策略模式。

迷你版的交易系统

大家可能对银行的交易系统充满敬畏之情,一听说是英航的IT人员立马想当然的认为这是个很厉害的人物,那我们今天就来对银行的交易系统做一个初步探讨。国内一家大型集团计划建立全国“一卡通”计划,每个员工配备一张IC卡,该卡基本上就是万能的,门禁系统用它,办公系统用他,你想打开自己的邮箱,没有他的甭想了,它还可以用来进行消费,比如到食堂吃饭,到园区内的商店消费,甚至洗澡、理发、借书、买书等都可以用他,只要这张卡内有余额,在集团内部就是一张借记卡。我们要讲解的就是“一卡通”项目联机交易子系统,类似于银行的交易系统,可以说他是交易系统的mini版吧。

该项目具有一定的挑战性,集团公司的架构分为三层:总部、省级分部、市级机构,业务要求是“一卡通”推广到全国,一名员工从北京出差到了上海,凭一卡通能在北京做的事情在上海同样能完成。对于联机交易子项目,异地分支机构与总部之间的通信采用了MQ传递消息,也就是我们观察者模式的BOSS版,与目前的通过POS机刷信用卡基本上是一个道理。

联机交易子系统有一个非常重要的子模块——扣款子模块。这个模块太重要了!从业务上来说,扣款失败就代表着所有的商业交易关闭,这是不允许发生的;从技术上来说,扣款的异常处理、事务处理、鲁棒性都是不容忽视的,特别是饭点时间,并发量是很恐怖的,这对架构师提出了很高的要求。

我们详细分析一下扣款子模块,每个员工都有一张IC卡,他的IC卡上有以下两种金额。

  • 固定金额

固定金额是指员工不能提现的金额,这部分金额只能用来特定消费,即员工日常必需的消费,例如食堂内、理发、健身等活动。

  • 自由金额

自由金额是可以提现的,当然也可以用于消费。每个月初,总部都会为每个员工的IC卡中打入固定数量的金额,然后提倡大家在集团内的商店消费。

在实际系统开发中,架构设计采用的是一张IC卡绑定两个账户:固定账户和自由账户,为了简化描述,还是使用固定金额和自由金额的概念。既然有消费,系统肯定有扣款处理,系统内有两套扣款规则。

  • 扣款策略一

该类型的扣款会对IC卡上的两个金额产生影响,计算公式如下:

IC卡固定余额=IC卡现有固定余额-交易金额/2

IC卡自由余额=IC卡现有自由金额-交易金额/2

也就是说,该类型的消费分别在固定金额和自由金额上各扣除一半。他适用于固定消费场景例如吃饭、理发等情况下的扣款,这么做是为了防止乱情况,你请别人吃饭时自己也要出一半。

  • 扣款策略二

全部从自由金额上扣除,由于集团内的各种消费、服务非常齐全,而且比市面价格稍低,员工还是很乐意到这里消费的,而且很多员工本身就住在集团附近,基本上就是“公司即家,家即公司”。

这里重点就是这两种消费的扣款策略该怎样设计?要知道这种联机交易,日后允许大规模变更的可能性基本上是零,所以系统设计的时候要做到可拆卸,避免日后维护的大量开支。

很明显,这是一个策略模式的实际应用,但是你还记得策略模式是有缺陷的吗?他的具体策略必须暴露出去,而且还要由上层模块初始化,这不合适,与迪米特法则有冲突,高层次模块对低层次的模块应该仅仅处在“接触”的层次上,而不应该是“耦合”的关系,否则,维护的工作量就会非常大。问题提出了,那我们就应该想办法来修改这个缺陷,正好工厂方法模式可以帮我们产生指定的对象,但是问题又来了,工厂方法模式要指定一个类,他才能产生对象,怎么办?引入一个配置文件进行映射,避免系统僵化情况的发生,我们以枚举类完成该任务。

还有一个问题,一个交易的扣款模式是固定的,根据其交易编号而定,那我们怎样把交易编号与扣款策略对应起来的?采用状态模式或责任链模式都可以,如果采用状态则认为交易编号就是一个交易对象的状态,对于一笔确定的交易(一个已经生成了的对象),他的状态不会从一个状态过渡到另一个状态,也就是说他的状态只有一个,执行完毕后即结束,不存在多状态的问题;如果采用责任链模式,则可以用交易编码作为链中的判断依据,由每个执行节点进行判断,返回相应的扣款模式。但是在实际中,采用了关系型数据库存储扣款规则与交易编码的对应关系,为了简化该部分,我们在下面的设计中使用了条件判断语句来代替。

还有,这么复杂的扣款模块总要进行一个封装吧,不能让上层业务模块直接深入到模块的内部,于是门面模式又摆在了眼前。

分析完毕,我们先定义交易中用到的两个类:IC卡类和交易类。

每个IC卡有三个属性,分别是IC卡好吗、固定金额、自由金额,然后通过getter/setter方法来访问,如下所示。

public class Card {
	// IC卡号码
	private String cardNo = "";
	// 卡内的固定交易金额
	private int steadyMoney = 0;
	// 卡内自由交易金额
	private int feeMoney = 0;

	public String getCardNo() {
		return cardNo;
	}

	public void setCardNo(String cardNo) {
		this.cardNo = cardNo;
	}

	public int getSteadyMoney() {
		return steadyMoney;
	}

	public void setSteadyMoney(int steadyMoney) {
		this.steadyMoney = steadyMoney;
	}

	public int getFeeMoney() {
		return feeMoney;
	}

	public void setFeeMoney(int feeMoney) {
		this.feeMoney = feeMoney;
	}

}

金额怎么都是整数类型?应该是double类型或者BigDecimal类型呀。是,一般非银行的交易系统,比如超市的收银系统,系统内都是存放的int类型,在显示的时候才转换为货币类型。

交易信息Trade类,负责记录每一笔交易,他是由监听程序监听MQ队列而产生的,有两个属性:交易编号和交易金额,其中的交易编号对整个交易非常重要,18位字符(在银行的交易系统中,这里可不是字符串,一般是十进制数字或二进制数字,要考虑系统的性能,数字运算可比字符运算快得多),包括POS机编号、商户编号、校验码等,我们这里暂时用不到,就不多做介绍,我们只要知道他是一个非常有用的编码就成。交易金额为整数类型,实际金额放大100倍即可。如下所示。

public class Trade {
	// 交易编号
	private String tradeNo = "";

	// 交易金额
	private int amount = 0;

	public String getTradeNo() {
		return tradeNo;
	}

	public void setTradeNo(String tradeNo) {
		this.tradeNo = tradeNo;
	}

	public int getAmount() {
		return amount;
	}

	public void setAmount(int amount) {
		this.amount = amount;
	}

}

两个最简单也是在应用中最常使用的对象定义完毕,下面就需要来定义策略了,非常明显的策略模式,扣款有两种策略:固定扣款和自由扣款。下面我们来看代码,先看抽象策略,也就是扣款接口,如下所示。

public interface IDeduction {
	/**
	 * 扣款,提供交易和卡信息,进行扣款,并返回扣款是否成功
	 * 
	 * @param card
	 * @param trade
	 * @return
	 */
	boolean exec(Card card, Trade trade);
}

固定扣款的规则是固定金额和自由金额各扣除交易金额的一半,如下所示。

public class SteadyDeduction implements IDeduction {

	@Override
	public boolean exec(Card card, Trade trade) {
		// 固定金额和自由金额各扣除50%
		int halfMoney = (int) Math.rint(trade.getAmount() / 2.0);
		card.setFeeMoney(card.getFeeMoney() - halfMoney);
		card.setSteadyMoney(card.getSteadyMoney() - halfMoney);
		return true;
	}

}

这个具体策略也非常简单,就是两个金额各自减去交易额的一半(注意除数是2.0,可不是2),然后再四舍五入,算法确实简单。该逻辑没有考虑账户余额不足的情况,也没有考虑异常情况,比如并发情况,一张卡有两笔消费同时发生时,是不是就发生错误了?一张卡同时有两笔消费会出现这种情况吗?会的,网络阻塞的情况,MQ多通道发送,在网络繁忙的情况下是有可能出现该问题,这里就不多介绍,有兴趣可以看看MQ的资料。我们在这里是一个快乐路径,认为所有的交易都是在安全可靠的环境中发生的,并且所有的系统环境都满足我们的要求。我们再来看另一个策略,这个策略更简单,如下所示。

public class FreeDeduction implements IDeduction {

	@Override
	public boolean exec(Card card, Trade trade) {
		// 直接从自由余额中扣除
		card.setFeeMoney(card.getFeeMoney() - trade.getAmount());
		return true;
	}

}

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

public class DeductionContext {
	// 扣款策略
	private IDeduction deduction = null;

	/**
	 * 构造函数传递策略
	 * 
	 * @param deduction
	 */
	public DeductionContext(IDeduction deduction) {
		this.deduction = deduction;
	}

	/**
	 * 执行扣款
	 * 
	 * @param card
	 * @param trade
	 * @return
	 */
	public boolean exec(Card card, Trade trade) {
		return this.deduction.exec(card, trade);
	}
}

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

通过StrategyMan负责对具体策略的映射,如下所示。

public enum StrategyMan {
	SteadyDeduction("com.test.SteadyDeduction"), 
	FreeDeduction("com.test.FreeDeduction");

	String value = "";

	private StrategyMan(String value) {
		this.value = value;
	}

	public String getValue() {
		return value;
	}
}

他是一个登记容器,所有的具体策略都在这里登记,然后提供给工厂方法模式。策略工厂如下所示。

public class StrategyFactory {
	/**
	 * 策略工厂
	 * 
	 * @param strategy
	 * @return
	 */
	public static IDeduction getDeduction(StrategyMan strategy) {
		IDeduction deduction = null;
		try {
			deduction = (IDeduction) Class.forName(strategy.getValue()).newInstance();
		} catch (InstantiationException | IllegalAccessException
				| ClassNotFoundException e) {
			e.printStackTrace();
		}
		return deduction;
	}
}

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

public class DeductionFacade {
	/**
	 * 对外公布的扣款信息
	 * 
	 * @param card
	 * @param trade
	 * @return
	 */
	public static Card deduct(Card card, Trade trade) {
		// 获得消费策略
		StrategyMan reg = getDeductionType(trade);
		// 初始化一个消费策略对象
		IDeduction deduction = StrategyFactory.getDeduction(reg);
		// 产生一个策略上下文
		DeductionContext context = new DeductionContext(deduction);
		// 进行扣款处理
		context.exec(card, trade);
		// 返回扣款处理完毕后的数据
		return card;
	}

	/**
	 * 获得对应的商户消费策略
	 * 
	 * @param trade
	 * @return
	 */
	private static StrategyMan getDeductionType(Trade trade) {
		// 模拟操作
		if (trade.getTradeNo().contains("abc")) {
			return StrategyMan.FreeDeduction;
		} else {
			return StrategyMan.SteadyDeduction;
		}
	}
}

注意一下getDeductionType方法,这个方法在实际项目中是存在的,但是与上面的写法有天壤之别,因为在实际项目中,数据库中保存了策略代码与交易编码的对应关系,直接通过数据库的SQL语句就可以返回对应的扣款策略。这里我们采用大家最熟悉的条件转移来实现,也是比较清晰和容易理解的。

可能要问了,在门面模式中已经明确的说明,门面类中不允许有业务逻辑存在,但是你这里还是有了一个getDeductionType方法,他可代表的是一个判断逻辑呀,这是为什么呢?是的,该方法完全可以移到其他Helper类中,由于我们是示例代码,暂没有明确的业务含义,故编写在此处,在实际应用中,请把该方法放置到其他类中。

测试类如下所示。

public class Client {
	/**
	 * 模拟交易
	 * 
	 * @param args
	 */
	public static void main(String[] args) {
		// 初始化一张IC卡
		Card card = initIC();
		// 显示一下卡内信息
		System.out.println("======初始卡信息:======");
		showCard(card);
		// 是否停止运行标志
		boolean flag = true;
		while (flag) {
			Trade trade = createTrade();
			DeductionFacade.deduct(card, trade);
			// 交易成功,打印出成功处理消息
			System.out.println("\n======交易凭证======");
			System.out.println(trade.getTradeNo() + " 交易成功! ");
			System.out.println("本次发生的交易金额为:" + trade.getAmount() / 100.0 + " 元");
			// 展示一下卡内信息
			showCard(card);
			System.out.print("\n是否需要退出?(Y/N)");
			if (getInput().equalsIgnoreCase("y")) {
				flag = false; // 退出
			}
		}
	}

	/**
	 * 初始化一个IC卡
	 * 
	 * @return
	 */
	private static Card initIC() {
		Card card = new Card();
		card.setCardNo("1100010001000");
		card.setFeeMoney(100000); // 1000元
		card.setSteadyMoney(80000); // 800元
		return card;
	}

	// 产生一条交易
	private static Trade createTrade() {
		Trade trade = new Trade();
		System.out.print("请输入交易编号:");
		trade.setTradeNo(getInput());
		System.out.print("请输入交易金额:");
		trade.setAmount(Integer.parseInt(getInput()));
		// 返回交易
		return trade;
	}

	/**
	 * 打印出当前卡内交易金额
	 * 
	 * @param card
	 */
	private static void showCard(Card card) {
		System.out.println("IC卡编号:" + card.getCardNo());
		System.out.println("固定类型余额:" + card.getSteadyMoney() / 100.0 + " 元");
		System.out.println("自由类型余额:" + card.getFeeMoney() / 100.0 + " 元");
	}

	/**
	 * 获得键盘输入
	 * 
	 * @return
	 */
	private static String getInput() {
		String str = "";
		try {
			str = (new BufferedReader(new InputStreamReader(System.in))).readLine();
		} catch (IOException e) {
			e.printStackTrace();
		}
		return str;
	}
}

类比较长,耐心看还是非常简单地,对其中Client类的方法说明如下:

  • initIC方法

初始化一张IC卡,方便进行测试。

  • createTrade方法

创建一笔交易,完成测试任务。

  • showCard方法

显示IC卡内的信息。

  • getInput方法

获得从键盘输入的字符,以回车符作为终结标志。

小结

回顾一下我们在该案例中使用了几个模式。

  • 策略模式

负责对扣款策略进行封装,保证两个策略可以自由切换,而且日后增加扣款策略也非常容易。

  • 工厂方法模式

修正策略模式必须对外暴露具体策略的问题,由工厂方法模式直接产生一个具体策略对象,而其他模块则不需要依赖具体的策略。

  • 门面模式

负责对复杂的扣款系统进行封装,封装的结果就是避免高层模块深入子系统内部,同时提供系统的高内聚、低耦合的特性。

我们主要使用了这三个模式,他们的好处是灵活、稳定,我们可以设想一下可能有哪些业务变化。

扣款策略变更

增加一个新扣款策略,三步就可以完成:实现IDeduction接口,增加StrategyMan配置项,扩展扣款策略的利用(也就是门面模式的getDeductionType方法,在实际项目中这里只需要增加数据库的配置项)。减少一个策略很简单,修改扣款策略的利用即可。变更一个扣款策略也很简单,扩展一个实现类就可以了。

变更扣款策略的利用规则

我们系统不想大修改,可以用状态模式,这个就是为策略的利用服务的,变更他就能满足需求。想把IC卡也纳入策略利用的规则也不复杂。其实这个变更还真发生了,系统投产后,业务提出考虑退休人员的情况,退休人员的IC卡与普通在职员工一样,但是他的扣款不仅仅是根据交易编码,还要根据IC卡对象,系统的变更做法是增加一个扣款策略,同时扩展扣款利用策略,也就是数据库的配置项,在getDeductionType中新扩展了一个功能:根据IC卡号,确认是否是退休人员,是退休人员,则使用新的扣款策略,这是一个非常简单的扩展。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值