设计模式之外观模式

这节接着讲设计模式：外观模式（Facade Pattern）。

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

外观（Facade）模式又叫作门面模式，是一种通过为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口，外部应用程序不用关心内部子系统的具体细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性。
在日常编码工作中，我们都在有意无意的大量使用外观模式。只要是高层模块需要调度多个子系统（2个以上的类对象），我们都会自觉地创建一个新的类封装这些子系统，提供精简的接口，让高层模块可以更加容易地间接调用这些子系统的功能。尤其是现阶段各种第三方SDK、开源类库，很大概率都会使用外观模式。

它有以下主要优点：

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

它的主要缺点如下：

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

下面通过代码看一下外观模式的实现：

class Program
{
    static void Main (string[] args)
    {
        Facade f = new Facade ();
        f.Method ();
        Console.ReadKey ();
    }
}

//外观角色
class Facade
{
    SubSysOne so = new SubSysOne ();
    SubSysTwo st = new SubSysTwo ();
    SubSysThree sthree = new SubSysThree ();

    public void Method ()
    {
        so.Method ();
        st.Method ();
        sthree.Method ();
    }
}

//子系统角色
class SubSysOne
{
    public void Method () => Console.WriteLine ("子系统1的方法被调用");
}
class SubSysTwo
{
    public void Method () => Console.WriteLine ("子系统2的方法被调用");
}
class SubSysThree
{
    public void Method () => Console.WriteLine ("子系统3的方法被调用");
}

运行结果如下：