设计模式之外观模式解析

关注

发布于: 2020 年 07 月 25 日

今天是设计模式学习系列的第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！
个人公众号
﻿
觉得写得还不错的小伙伴麻烦动手点赞+关注；
文章如果存在不正确的地方，麻烦指出，非常感谢您的阅读；
推荐大家关注我的公众号，会为你定期推送原创干货文章，拉你进优质学习社群；
github地址：github.com/coderluojust/qige_blogs
﻿