【设计模式In Java】九、外观模式

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/CL_YD/article/details/88075615

外观模式

定义

外观模式(Facade Pattern)：为子系统中的一组接口提供一个统一的入口。外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

外观模式中，一个子系统的外部与其内部的通信通过一个统一的外观类进行，外观类将客户类与子系统的内部复杂性分隔开，使得客户类只需要与外观角色打交道，而不需要与子系统内部的很多对象打交道。

场景

现在有一个复杂的系统，有很多子系统或子模块构成，并且每个子系统和子模块都可以单独停止和启动，但是部分子系统的启停会导致另一些子系统的启停，如果把启停逻辑写在客户端，那么客户端的代码可能相当复杂且不好维护。这时候可以使用外观模式，给所有子系统的启停都提供相同的外观，客户端只需要关心需要操作的具体子系统是哪一个就好了。

UML类图

代码

facade
示例：

public class TestFacade {

    @Test
    public void test() {
        new WebServiceController().start();
        new WebServiceController().shutdown();

        new KafkaServiceController().start();
        new KafkaServiceController().shutdown();
    }
    /*
    MySQL server started...
    Web server started...

    Web server has been shut down...
    MySQL server has been shut down...

    Zookeeper server started...
    Kafka server started...

    Kafka server has been shut down...
    Zookeeper server has been shut down...

     */

}

总结

感觉和适配器模式的目的有相似之处：都是用已有的代码去适配一个统一的方法，达到统一管理或一致外观的目的，但是基于设计来看的话，适配器模式是一对一的适配，而外观模式可能是一对多的“适配”。

外观模式屏蔽了子系统，客户端使用时感觉不到子系统的存在，客户端不用管理复杂的子系统，子系统内部变化也不会影响到外观，即使要为外观添加新的子系统，客户端也是没有感知的；扩展子系统和外观的时候也不会影响到已有的子系统和外观。所以外观模式特别适合使用在那些需要为复杂的子系统提供一个统一外观的场景，比如菜单、统一控制、多源聚合等。

外观模式并不能直接限制客户端直接使用子系统，当同类子系统存在多个且没有关联的时候，可能还需要客户端传入子系统，这跟客户端直接使用子系统没有多大区别，所以外观模式的使用还是有一些不可控。当外观中需要添加新的子系统时，不可避免地需要修改具体外观类，这也违背了开闭原则。