外观模式

　　外观模式（Facade）,为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

　　我们来看具体的代码实现：

　　三个子系统类：

　　

package facade;

public class SubSystemOne {
    public void methodOne() {
        System.out.println("子系统方法一");
    }
}

public class SubSystemTwo {
    public void methodTwo() {
        System.out.println("子系统方法二");
    }
}

public class SubSystemThree {
    public void methodThree() {
        System.out.println("子系统方法三");
    }
}

门面类：

public class Facade {
    private SubSystemOne systemOne;
    private SubSystemTwo systemTwo;
    private SubSystemThree systemThree;
    
    public Facade(){
        systemOne = new SubSystemOne();
        systemTwo = new SubSystemTwo();
        systemThree = new SubSystemThree();
    }
    
    public void facadeMethodOne(){
        systemOne.methodOne();
        systemThree.methodThree();
    }
    
    public void facadeMethodTwo(){
        systemTwo.methodTwo();
        systemThree.methodThree();
    }
}

客户端调用：

public class Main {
    public static void main(String[] args) {
        Facade facade = new Facade();
        
        facade.facadeMethodOne();
        
        facade.facadeMethodTwo();
    }
}

　　我们从代码可以看出，外观模式很好的体现了依赖倒转原则和迪米特法则，是非常常用的模式之一。

　　那么，何时使用外观模式呢？

　　首先，在设计初期阶段，应该有意识的将不同的两个层分离，比如经典的三层架构，就需要在数据访问层与业务逻辑层、业务逻辑层与表示层之间建立外观facade，这样可以为复杂的子系统提供一个简单的接口，使得耦合度大大降低。

　　其次，在开发阶段，子系统往往因为不断的重构演化而变得越来越复杂，会产生很多小的类，增加facade，可以提供简单的接口，减少他们之间的依赖。

　　然后，在维护一个遗留的大系统时，可能这个系统已经非常难以维护和拓展了，但因为它包含重要的接口，新的功能开发必须要依赖它，那么就可以建立facade，新系统与facade交互，facade与旧系统交互。