设计模式之外观模式解析

今天是设计模式学习系列的第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() 方法即可。这就是简化的接口,调用它就一切搞定了。

定义外观模式

提供了一个统一的接口,用来访问子系统中的一群接口。外观定义了一个高层接口,让子系统更容易使用。

上面的概念很容易理解,不过请记住模式的意图,是提供一个简单的接口,好让一个子系统更易使用。 从下面的类图也可以感受到这一点:

设计模式之外观模式解析_第1张图片

全部的内容就是这样了,是不是很简单,恭喜你又学会了一个设计模式!

现在我们来学一个新的 OO 设计原则。

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

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

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

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

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

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

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

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

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

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

全文完,fighting!

你可能感兴趣的:(设计模式,设计模式,java,外观模式)