外观模式

外观模式我觉得应该是很多人说的门面模式。现在流行的微服务网关我认为就是一个外观模式的经典体现。他是建立在外观模式基础上构建的更复杂的模式。掌握了外观模式就会很容易理解微服务网关的作用。

 

                                                                                                                                                                                                                                                                                             场景问题

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

生活场景

现在你要需要电脑（当然重点不是电脑），而是你需要电脑，就需要去市场买电脑各个配件。你需要挨个挨个的去各个配件店里买配件，然后才能回家组装。但是随着社会的发展，就会产生一些新的服务行业，比如装机公司，于是形成下面的商业模式

 

好了，现在你只需要把需求告诉装机公司，通过访问装机公司，然后告诉它你的需求，然后它会调用后面的配件店，最后组装一台你想要的电脑给你。你不需要知道市场上那么多的配件店以及每个配件的市场，价格，性能等等。服务公司总是让客户朝着傻逼的方向发展的。这个是不会有问题的。

 

引入问题

 

如何实现，才能让客户端技能简单的使用系统的各个子模块，而又不需要客户端去和子模块交互呢？

 

 

                                                                                                                                解决方案

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

术语解释

界面

        这里说的界面不是GUI，而是指的门面，就是客户端需要面对的对象

接口

        这里说的接口不是Java中的interface，而是客户所面对的对象给客户提供出来的一套交互服务，可以是方法。

模块

        在微服务中就是各个微服务系统，在单体中就是内部的各个业务模块，各个模块不知道门面，但是门面知道各个模块

 

外观（门面）提供接口给客户端，客户不需要知道具体的模块，客户只需要和外观之间约定好需求就行。外观（门面）会屏蔽客户和具体模块。

 

示例代码

外观模式的结构如图过于抽象，因此将他们具体化。

假设子系统又三个模块，分别是AModule,BModule,CModule

 

public interface AModuleApi {

    void testA();

}

public class AModuleImplimplements AModuleApi {

    @Override

    public void testA() {

        System.out.println("testA方法执行...");

    }

}

BModuleApi和CModuleApi和上面一样的写法，然后写门面类，门面类提供给调用者接口，调用者通过门面的接口就可以完成个模块的组合调用

public class Facade {

    /**

    * 示意方法，满足客户需要的功能

    */

    public void test(){

        AModuleApi a =new AModuleImpl();

        BModuleApi b =new BModuleImpl();

        CModuleApi c =new CModuleImpl();

        a.testA();

        b.testB();

        c.testC();

    }

}

 

入口调用

public static void main(String[] args) {

    new Facade().test();

}

 

 

 

                                                                                                                                         模式说明

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

外观模式不是给系统添加新的功能接口，而是为了减少调用者和功能接口间的耦合。

外观是作为子系统对外的接口出现的，虽然也可以再外观里定义一些子系统没有的功能，但是不建议也没必要这么做。

 

外观应该是包装已经有的若干功能，组合起来提供给客户，而不是添加新得实现

也许各位看官会说，不就是把各个模块得功能挪到Facade类中嘛，这就叫设计模式？

没错，这就是外观模式。外观模式是系统这边的。如果调用方需要频繁的调用ABC各个模块，那么完全可以将他们组装到外观中。这样一来好处多多，客户不必知道ABC各个细节了，直接一个外观就搞定了，如果客户仅仅是只需要调用一个功能接口那也就没必要同年过外观，也可以直接调用模块功能。

 

因为现在一个系统会拆分成各个晓得业务系统，每个业务系统也会根据功能拆分成更小的系统。如果不适用外观模式，那么意味着调用者就会跟很多微服务（模块）打交道，这时候会加大学习成本，加大调用成本，如果我们充分利用好外观模式，客户只需要面对门面，无需了解里面的具体。这样系统才会更好 

 

外观模式简单易用，体现了最少知识原则。但是一定程度上外观模式也不可滥用。

 

 

外观模式的延申就是微服务中的网关，思考一下

网关中配置了各个模块子系统，每个子系统提供了接口

只需要访问网关去调用接口，那么接口会组装各个功能，最终实现客户需求。