设计模式系列18—外观模式

1 外观模式的定义与特点

在现实生活中，常常存在办事较复杂的例子，如办房产证或注册一家公司，有时要同多个部门联系，这时要是有一个综合部门能解决一切手续问题就好了。

软件设计也是这样，当一个系统的功能越来越强，子系统会越来越多，客户对系统的访问也变得越来越复杂。这时如果系统内部发生改变，客户端也要跟着改变，这违背了“开闭原则”，也违背了“迪米特法则”，所以有必要为多个子系统提供一个统一的接口，从而降低系统的耦合度，这就是外观模式的目标。

下图给出了客户去当地房产局办理房产证过户要遇到的相关部门

1.1 定义

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

1.2 结构

外观（Facade）模式的结构比较简单，主要是定义了一个高层接口。它包含了对各个子系统的引用，客户端可以通过它访问各个子系统的功能。现在来分析其基本结构和实现方法。
外观（Facade）模式包含以下主要角色。

• 外观（Facade）角色：为多个子系统对外提供一个共同的接口。
• 子系统（Sub System）角色：实现系统的部分功能，客户可以通过外观角色访问它。
• 客户（Client）角色：通过一个外观角色访问各个子系统的功能。
  

2 外观模式的优缺点

2.1 优点

外观（Facade）模式是“迪米特法则”的典型应用，它有以下主要优点。

• 降低了子系统与客户端之间的耦合度，使得子系统的变化不会影响调用它的客户类。
• 对客户屏蔽了子系统组件，减少了客户处理的对象数目，并使得子系统使用起来更加容易。
• 降低了大型软件系统中的编译依赖性，简化了系统在不同平台之间的移植过程，因为编译一个子系统不会影响其他的子系统，也不会影响外观对象。

2.2 缺点

外观（Facade）模式的主要缺点如下。

• 不能很好地限制客户使用子系统类。
• 增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。

3 外观模式的使用场景

通常在以下情况下可以考虑使用外观模式。

• 对分层结构系统构建时，使用外观模式定义子系统中每层的入口点可以简化子系统之间的依赖关系。
• 当一个复杂系统的子系统很多时，外观模式可以为系统设计一个简单的接口供外界访问。
• 当客户端与多个子系统之间存在很大的联系时，引入外观模式可将它们分离，从而提高子系统的独立性和可移植性。

4 外观模式的实现

示例：
1，子系统角色，由若干个类组成

public class SubClass1 {    
    public void method1(){
        System.out.println("这是子系统类1中的方法1");
    }    
    public void method2(){
        System.out.println("这是子系统类1中的方法2");
    }
}
public class SubClass2 {    
    public void method1(){
        System.out.println("这是子系统类2中的方法1");
    }    
    public void method2(){
        System.out.println("这是子系统类2中的方法2");
    }
}
public class SubClass3 {   
    public void method1(){
        System.out.println("这是子系统类3中的方法1");
    }    
    public void method2(){
        System.out.println("这是子系统类3中的方法2");
    }
}

2，外观角色类

public class FacadeClass {    
    public void FacadeMethod(){
        SubClass1 s1 = new SubClass1();
        s1.method1();
        SubClass2 s2 = new SubClass2();
        s2.method1();
        SubClass3 s3 = new SubClass3();
        s3.method1();
    }
}

3，客户端测试方法

public class ClientClass {
    public static void main(String[] args) {
        FacadeClass fc = new FacadeClass();
        fc.FacadeMethod();
    }
}

Facade类其实相当于子系统中SubClass类的外观界面，有了这个Facade类，那么客户端就不需要亲自调用子系统中的那些具体实现的子类了，也不需要知道系统内部的实现细节，甚至都不需要知道这些子类的存在，客户端只需要跟Facade类交互就好了，从而更好地实现了客户端和子系统中具体类的解耦，让客户端更容易地使用系统。

同时，这样定义一个Facade类可以有效地屏蔽内部的细节，免得客户端去调用Module类时，发现一些不需要它知道的方法。如上代码，我的所有子类中的方法二都是方法一调用的方法，是配合方法一的，他们不需要被客户端调用，而且具有一定的保密性，这样使用外观模式时就可以不被客户端知道

5 外观模式常见问题

5.1 外观模式的扩展

在外观模式中，当增加或移除子系统时需要修改外观类，这违背了“开闭原则”。如果引入抽象外观类，则在一定程度上解决了该问题，其结构图如图所示。

5.2 外观模式的总结

• 1、外观模式为复杂子系统提供了一个简单接口，并不为子系统添加新的功能和行为。
• 2、外观模式实现了子系统与客户端之间的松耦合关系。
• 3、外观模式没有封装子系统的类，只是提供了简单的接口。 如果应用需要，它并不限制客户使用子系统类。因此可以灵活的在系统易用性与通用性之间选择。
• 4、外观模式注重的是简化接口，它更多的时候是从架构的层次去看整个系统，而并非单个类的层次。