机房收费系统合作版，是我们第三次与机房收费系统相遇的时刻。在个人重构的时候，我们就开始了“七层架构”之旅，其中外观模式是单独作为一层来开发的。
那个时候，也不理解外观是起到怎样一个作用，大话上的解释表面上容易理解，看完后自己也觉得很有道理。但在系统程序中，自己是只要经过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层代码截图：
这样子，才是真正实现了外观模式的作用。这样子，才算是真正体会到了外观模式的魅力。这样子，才算是解决系统的耦合性问题。
机房合作的这一路，坎坎坷坷，原本打算速战速决，可那是想的。事实上，这一路，特别漫长。每件事组长都必须亲力亲为，这既是责任，也是考验。从现在看来，这其实更是学习的机会，虽然经历过了，但再一次遇见，一定会有不一样的精彩。也正是因为自己一次次放下，一次次又捡起，才让我，重新认识了外观模式，真正认识了外观模式。
