今天是设计模式学习系列的第8篇–外观模式。
开篇问题
- 什么是外观模式？
- 外观模式和适配器模式的区别？
外观模式解析
首先我们先看一个场景，我们平常肯定都是用银行的app，在注册时，都要经过实名认证这个步骤。但是实名这个功能它是非常复杂的，包括验密、上传证件、OCR识别、联网核查等不同的步骤。如果一个客户要使用实名这个功能如果要他一个个对接，那估计头都大了，对接是如此的复杂。 怎么办？
接下来我们看看外观模式如何解决这团混乱，好让平台客户可以轻松的使用实名功能。
有了外观模式，通过实现一个提供更合理接口的外观类，就可以将我们复杂的实名流程涉及的子系统变得更容易使用。
代码如下：
public class RealNameSysFacade {
PassVerify pvf;
UploadCer uc;
OCRIdentify ocri;
OnlineVer ov;
public RealNameSysFacade(PassVerify pvf, UploadCer uc, OCRIdentify ocri, OnlineVer ov) {
this.pvf = pvf;
this.uc = uc;
this.ocri = ocri;
this.ov = ov;
}
public boolean realNameVerify(Request request) {
System.out.println("get ready to realname ...");
pvf.process();
uc.process();
// 其他方法
}
}
客户使用实名功能，只需要调用 RealNameSysFacade 的 realNameVerify() 方法即可。这就是简化的接口，调用它就一切搞定了。
定义外观模式
提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。
上面的概念很容易理解，不过请记住模式的意图，是提供一个简单的接口，好让一个子系统更易使用。 从下面的类图也可以感受到这一点：
全部的内容就是这样了，是不是很简单，恭喜你又学会了一个设计模式！
现在我们来学一个新的 OO 设计原则。
最少知识原则：只和你的密友交谈。
这块有点人性化哈，说白了就是希望我们在设计中，不要耦合太多类在一起，我们也经常见系统中修改一个类结果一搜发现到处有调用，非常的头疼，后期维护成本也很高，新人也不容易看懂导致不敢改。
这里你可能会问，这个原则具体的方法是什么呢？如何符合最少知识原则？
这里我给你列举下，对于任何对象类而言，在该对象内的方法调用,我们应该只调用以下范围的方法：
- 该对象本身；
- 被当做方法参数传递进来的对象；
- 此方法所创建或实例化的任何对象；
- 对象的任何组件；
前三条方针告诉我们，如果是调用其他方法返回的对象，我们不要调用该对象的方法！ 第四条是说把 “组件” 想象成是被实例变量所引用的任何对象，换句话说，把这想象成是 “有一个”（HAS-A） 关系。
外观模式和适配器模式的区别
你可能会感觉外观模式也是组合了一些组件，对外提供一个统一接口，而适配器也是组合了其他组件对外提供目标接口，但是这两者的出发点是不同的；
- 当需要使用一个现有的类而其接口并不符合你的需要时，就使用适配器；
- 当需要简化并统一一个很大的接口或者一群复杂的接口时，使用外观；
- 适配器改变接口以符合客户的期望；
- 外观将客户从一个复杂的子系统中解耦；
- 实现一个适配器可能需要一番功夫，也可能不费功夫，视目标接口的大小与复杂度而定；
- 实现一个外观，需要将子系统组合进外观中，然后将工作委托给子系统执行；
- 可以为一个子系统实现一个以上的外观，如果子系统太复杂的话，可以分多个层次；
相信看完本文的描述，你应该又掌握了一个设计模式，恭喜你！ 记着一定要带着问题定期在自己脑海中复习，形成自己的知识体系，然后结合工作日常实践，不然很容易忘记。
全文完，fighting！