前言

今天我们来介绍外观模式，考虑外观模式较为简单且非常常见（平时开发中所处可见），就直接开门见山。

一、模式定义

外观模式(Facade Pattern)：又叫作门面模式，是一种通过为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口，外部应用程序不用关心内部子系统的具体细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性。

咋一看定义好像还挺复杂哈，仔细一想，这不就是封装嘛。平时在开发中，我们经常把一些复杂逻辑封装成方法或接口来供别人调用，这就是外观模式（是不是瞬间就学会了？）

二、模式结构

外观模式一般包含如下角色

Facade：外观角色

为多个子系统对外提供一个共同的接口

class Facade { private SubSystemA obj1 = new SubSystemA(); private SubSystemB obj2 = new SubSystemB(); private SubSystemC obj3 = new SubSystemC(); public void Method() { obj1.MethodA(); obj2.MethodB(); obj3.MethodC(); } }

Sub System：子系统角色

实现系统的部分功能，客户可以通过外观角色访问它

class SubSystemA { public void MethodA() { //业务实现代码 } } class SubSystemB { public void MethodB() { //业务实现代码 } } class SubSystemC { public void MethodC() { //业务实现代码 } }

三、模式结构图

四、优缺点

优点 它对客户端屏蔽了子系统组件，减少了客户端所需处理的对象数目，并使得子系统使用起来更加容易。通过引入外观模式，客户端代码将变得很简单，与之关联的对象也很少它实现了子系统与客户端之间的松耦合关系，这使得子系统的变化不会影响到调用它的客户端，只需要调整外观类即可一个子系统的修改对其他子系统没有任何影响，而且子系统内部变化也不会影响到外观对象 缺点 不能很好地限制客户端直接使用子系统类，如果对客户端访问子系统类做太多的限制则减少了可变性和灵活性如果设计不当，增加新的子系统可能需要修改外观类的源代码，违背了开闭原则

五、使用场景

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