外观模式（Facade）

即使你没有听说过外观模式，也完全有可能在很多时候使用过它。

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

外观模式结构图

外观模式代码结构

四个子系统的类
class SubSystemOne
{
    public void MethodOne( )
    {
        //do something
    }
}
class SubSystemTwo
{
    public void MethodTwo( )
    {
        //do something
    }
}
class SubSystemThree
{
    public void MethodThree( )
    {
        //do something
    }
}
class SubSystemFour
{
    public void MethodFour( )
    {
        //do something
    }
}

外观类
它需要了解所有的子系统的方法或属性，进行组合，以备外界调用
class Façade
{
    SubSystemOne one;
    SubSystemTwo two;
    SubSystemThree three;
    SubSystemFour four;
    public Façade()
    {
        one = new SubSystemOne( );
        two = new SubSystemTwo( );
        three = new SubSystemThree three;
        four = new SubSystemFour four;
    }
    public void MethodA()
    {//方法组A
        one.MethodOne();
        Three.MethodThree();
    }
    public void MethodB()
    {//方法组B
        two.MethodTwo();
        four.MethodFour();
    }
    ...定义更多的适合逻辑的算法方法组
    }

客户端调用
由于Facade的作用，客户端不必了解三个子系统的存在。
Façade façade = new Façade();
façade.MethodA();
façade.MethodB();

外观模式总结

外观模式完美地体现了依赖倒转原则和迪米特法则的思想，所以是非常常用的模式之一。

外观模式的结构

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

如何使用外观模式？

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

其次，在开发阶段，子系统往往因为不断地重构演化而变得越来越复杂，大多数的模式使用也会产生许多小的类，这增加了使用上的困难。增加外观Facade可以提供一个简单的接口，减少它们之间的依赖。

第三，在维护一个遗留的大型系统时，可能这个系统以及非常难以维护和拓展了，但因为它包含非常重要的功能，新的需求开发必须依赖于它。此时用外观模式Facade时非常合适的。为新系统开发一个外观Facade类，来提供设计粗糙或高度复杂的遗留代码的比较清晰的接口，让新系统与Facade对象交互，Facade与遗留代码交互所有复杂的工作。

外观模式应用场景

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

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

外观模式优缺点

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

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

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

1. 不能很好地限制客户使用子系统类，很容易带来未知风险。
2. 增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。