设计模式之七——外观模式

1 介绍

外观模式又称为门面模式，它是一种对象结构型模式。外观模式是迪米特法则的一种具体实现，通过引入一个新的外观角色可以降低原有系统的复杂度，同时降低客户类与子系统的耦合度。

1.1 什么是****模式

外观模式(Facade Pattern)：外部与一个子系统的通信必须通过一个统一的外观对象进行，为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

1.2 解决了什么问题

现代的软件系统都非常复杂，尽管我们已经想尽一切方法将其“分而治之”，把一个系统划分为好几个较小的子系统了，但是仍然可能会存在这样的问题：子系统内有非常多的类，客户端往往需要和许多对象打交道之后才能完成想要完成的功能。
门面模式就是解决这种不便的方式。

2 原理

外观模式包含两个角色：

Facade：外观角色。客户端可以调用这个角色的方法。此角色知晓相关的（一个或者多个）子系统的功能和责任。在正常情况下，本角色会将所有从客户端发来的请求委派到相应的子系统去。
SubSystem：子系统角色。可以有一个或者多个子系统角色，每一个子系统可以不是一个单独的类，而是一个类的集合，它实现子系统的功能；每一个子系统都可以被客户端直接调用，或者被外观角色调用，它处理由外观类传过来的请求；子系统并不知道外观的存在，对于子系统而言，外观角色仅仅是另外一个客户端而已。

外观模式的目的不是给予子系统添加新的功能接口，而是为了让外部减少与子系统内多个模块的交互，松散耦合，从而让外部能够更简单地使用子系统。

2.1 uml图

门面模式没有一般化的类图，这里放上结构图

结构图

image.png

2.2 代码示例

SubSystem代码示例

public class ModuleA {
    //示意方法
    public void testA(){
        System.out.println("调用ModuleA中的testA方法");
    }
}

public class ModuleB {
    //示意方法
    public void testB(){
        System.out.println("调用ModuleB中的testB方法");
    }
}


public class ModuleC {
    //示意方法
    public void testC(){
        System.out.println("调用ModuleC中的testC方法");
    }
}

Facade代码示例

public class Facade {
    //示意方法，满足客户端需要的功能
    public void test(){
        ModuleA a = new ModuleA();
        a.testA();
        ModuleB b = new ModuleB();
        b.testB();
        ModuleC c = new ModuleC();
        c.testC();
    }
}

调用示例

 Facade facade = new Facade();
 facade.test();

运行结果

略

2.3 优缺点

优点
- 松散耦合。实现了子系统与客户之间的松耦合关系，这使得子系统的组件变化不会影响到调用它的客户类，只需要调整外观类即可。
- 简单易用。对客户屏蔽子系统组件，减少了客户处理的对象数目并使得子系统使用起来更加容易。通过引入门面模式，客户代码将变得很简单，与之关联的对象也很少。
- 更好的划分访问层次
缺点
- 不能很好地限制客户使用子系统类，如果对客户访问子系统类做太多的限制则减少了可变性和灵活性。
- 在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。

3 适用场景

当要为一个复杂子系统提供一个简单接口时可以使用外观模式。该接口可以满足大多数用户的需求，而且用户也可以越过外观类直接访问子系统。
客户程序与多个子系统之间存在很大的依赖性。引入外观类将子系统与客户以及其他子系统解耦，可以提高子系统的独立性和可移植性。
在层次化结构中，可以使用外观模式定义系统中每一层的入口，层与层之间不直接产生联系，而通过外观类建立联系，降低层之间的耦合度。

系统演化过程中使用Facade的时机：

首先，在设计初期阶段，应该要有意识的将不同的两个层分离，层与层之间建立外观Facade；
其次，在开发阶段，子系统往往因为不断的重构演化而变得越来越复杂，增加外观Facade可以提供一个简单的接口，减少它们之间的依赖。
第三，在维护一个遗留的大型系统时，可能这个系统已经非常难以维护和扩展了，为新系统开发一个外观Facade类，来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口，让新系统与Facade对象交互，Facade与遗留代码交互所有复杂的工作。

4 总结

一个系统可以有多个外观类，每个外观类都负责和一些特定的子系统交互，向用户提供相应的业务功能。在很多情况下为了节约系统资源，一般将外观类设计为单例类。
不要试图通过外观类为子系统增加新行为。外观模式的用意是为子系统提供一个集中化和简化的沟通渠道，而不是向子系统加入新的行为，新的行为的增加应该通过修改原有子系统类或增加新的子系统类来实现，不能通过外观类来实现。
外观类充当了客户类与子系统类之间的“第三者”，降低了客户类与子系统类之间的耦合度。
外观模式最大的缺点在于违背了“开闭原则”，引入抽象外观类可以解决，也就是面向接口编程。

参考书籍及文章
1.《Java与模式》，电子工业出版社，阎宏

《大话设计模式》，清华大学出版社，程杰
《设计模式——可复用面向对象软件的基础》，机械工业出版社，Erich Gamma，Richard Helm，Ralph Johnson，John Vlissides
《Head First 设计模式（中文版）》，中国电力出版社
《图说设计模式》，https://design-patterns.readthedocs.io/zh_CN/latest/index.html
《设计模式Java版》，https://legacy.gitbook.com/book/quanke/design-pattern-java/details