设计模式之外观模式解析

今天是设计模式学习系列的第8篇–外观模式。

开篇问题

1. 什么是外观模式？
2. 外观模式和适配器模式的区别？

外观模式解析

首先我们先看一个场景，我们平常肯定都是用银行的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 设计原则。

最少知识原则：只和你的密友交谈。

这块有点人性化哈，说白了就是希望我们在设计中，不要耦合太多类在一起，我们也经常见系统中修改一个类结果一搜发现到处有调用，非常的头疼，后期维护成本也很高，新人也不容易看懂导致不敢改。

这里你可能会问，这个原则具体的方法是什么呢？如何符合最少知识原则？

这里我给你列举下，对于任何对象类而言，在该对象内的方法调用,我们应该只调用以下范围的方法：

1. 该对象本身；
2. 被当做方法参数传递进来的对象；
3. 此方法所创建或实例化的任何对象；
4. 对象的任何组件；

前三条方针告诉我们，如果是调用其他方法返回的对象，我们不要调用该对象的方法！ 第四条是说把 “组件” 想象成是被实例变量所引用的任何对象，换句话说，把这想象成是 “有一个”（HAS-A） 关系。

外观模式和适配器模式的区别

你可能会感觉外观模式也是组合了一些组件，对外提供一个统一接口，而适配器也是组合了其他组件对外提供目标接口，但是这两者的出发点是不同的；

1. 当需要使用一个现有的类而其接口并不符合你的需要时，就使用适配器；
2. 当需要简化并统一一个很大的接口或者一群复杂的接口时，使用外观；
3. 适配器改变接口以符合客户的期望；
4. 外观将客户从一个复杂的子系统中解耦；
5. 实现一个适配器可能需要一番功夫，也可能不费功夫，视目标接口的大小与复杂度而定；
6. 实现一个外观，需要将子系统组合进外观中，然后将工作委托给子系统执行；
7. 可以为一个子系统实现一个以上的外观，如果子系统太复杂的话，可以分多个层次；

---

相信看完本文的描述，你应该又掌握了一个设计模式，恭喜你！ 记着一定要带着问题定期在自己脑海中复习，形成自己的知识体系，然后结合工作日常实践，不然很容易忘记。

全文完，fighting！