【机房合作】重新认识外观模式

  1. 云栖社区>
  2. 博客>
  3. 正文

【机房合作】重新认识外观模式

leanring 2015-08-06 19:40:00 浏览672
展开阅读全文
	机房收费系统合作版,是我们第三次与机房收费系统相遇的时刻。在个人重构的时候,我们就开始了“七层架构”之旅,其中外观模式是单独作为一层来开发的。
	那个时候,也不理解外观是起到怎样一个作用,大话上的解释表面上容易理解,看完后自己也觉得很有道理。但在系统程序中,自己是只要经过BLL逻辑层的一个方法,就需要再经过一次外观,从而“解除耦合”,避免了UI层与BLL层之间直接传递数据。
	那个时候,在敲代码的时候就有一种感觉:每次写完B层逻辑,又要在F层重新写一次,这就是在解耦和吗?外观模式就是这样的吗?后来同学之间也交流过,发现有些人就干脆直接跳过外观,BLL层与UI层之间建立起了联系。
	而我还是坚持从始至终都使用了外观的,下面是个人重构的时候充值的BLL层代码截图:
 	Facade层的代码截图:
 	可以看出,我的Facade外观层实际上就是与我的BLL逻辑层的方法一一对应。这难道就是外观模式的应用吗?
	答案是:No	下面两张截图是机房合作的Facade层和BLL层的第二版代码,
	外观层变得很简单了,只需要实例化一个BLL层,调用其中的方法:
		而所有的一系列逻辑判断都在其中的RechargeBLL层,这里面还实例化了两个其它类的BLL层:
		在个人重构的时候,大部分判断提示都是写在了UI层,这样是不符合常理的。第二版代码进步的一点就在于把所有的逻辑判断都放在了BLL层。
	比如说充值这一业务,就包含多个判断:第一,判断充值卡号是否存在,给予提示;第二,判断充值卡号是否使用,给予提示;第三,查询该卡号余额;第四,执行充值,更新余额,给予提示。
	而前面三个业务判断都属于BLL层中的其他类,现在又同时堆积在了一个RechargeBLL类中,这样外观层真的起到作用了吗?
	答案是:No	在看机房合作最后一版的代码截图之前,先温习一下大话中是如何给我们讲解外观模式的。
	外观模式(Facade),为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。
	这个定义个人觉得很抽象,读完后,感觉有道理,但好像始终不能理解其中的深刻内涵。所以,我还是拿充值这一业务逻辑,来重新认识外观模式。
	下面是加上了外观模式的充值业务的外观层类图	其中下面三个BLL层就相当于书上说的各个子系统,因为这一个业务涉及到多个BLL层中的类,这时候外观就可以起到作用了。外观层表面上看起来只有一个方法,其实它就是书上说到的方法组,“外观类,它需要了解所有的子系统的方法或属性,进行组合,以备外界使用。”
	下面是改进后的充值Facade层代码截图:
		BLL层代码截图:
		这样子,才是真正实现了外观模式的作用。这样子,才算是真正体会到了外观模式的魅力。这样子,才算是解决系统的耦合性问题。

	机房合作的这一路,坎坎坷坷,原本打算速战速决,可那是想的。事实上,这一路,特别漫长。每件事组长都必须亲力亲为,这既是责任,也是考验。从现在看来,这其实更是学习的机会,虽然经历过了,但再一次遇见,一定会有不一样的精彩。也正是因为自己一次次放下,一次次又捡起,才让我,重新认识了外观模式,真正认识了外观模式。

网友评论

登录后评论
0/500
评论
leanring
+ 关注