【设计模式】外观（门面）模式

Facade Pattern

外部与一个子系统的通信必须通过一个统一的外观（Facade）对象进行，这就是外观模式。

• 外观模式要求一个子系统的外部与其内部的通信必须通过一个统一的外观（Facade）对象进行。外观模式提供一个高层次的接口，是的子系统更易于使用。
• 外观模式的外观类将客户端与子系统的内部复杂性分隔开，使得客户端只需要与外观对象打交道，而不需要与子系统内部的很多对象打交道。

外观模式的结构

• 外观（Facade）角色
  客户端可以调用这个角色的方法。此角色知晓相关的（一个或者多个）子系统的功能和责任。在正常情况下，本角色会将所有从客户端发来的请求委派到相应的子系统去。
• 子系统（subsystem）角色
  可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类，而是一个类的集合。每一个子系统都可以被客户端直接调用，或者被门面角色调用。子系统并不知道门面的存在，对于子系统而言，门面仅仅是另外一个客户端而已。

【GOF】的书中指出
在外观模式中，通常只需要一个外观类，并且此外观类只有一个实例，换言之它是一个单例类。当然这并不意味着在整个系统里只能有一个外观类，而仅仅是说对每一个子系统只有一个外观类。或者说，如果有一个系统有好几个子系统的话，每一个子系统有一个外观类，整个系统可以有数个外观类。

当客户程序与抽象类的实现部分之间存下着很大的依赖性，引入Facade将这个子系统与客户一集其他的子系统分离，为一个复杂子系统提供一个简单接口，Facade可以提供一个简单地缺省视图，这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过Facade层。可以提高子系统的独立性和可移植性。

• 在层次化结构中，可以使用Facade模式定义系统中每一层的入口点，如果子系统之间是相互依赖的，则可以让他们仅通过Facade进行通信，从而简化他们之间的依赖关系。
• 希望包装或隐藏原有系统：Facade可以把原有系统作为自己的私有成员。原有系统与Facade类联系在一起，但使用Facade类的客户无法看到原有的系统。
  维护一个一流的大型系统。
  跟踪对系统的使用——强迫所有客户通过Facade使用原有系统。

举例外观模式结构

namespace 外观模式
{
    //子系统类
    class SubSystemOne
    {
        public void MethodOne()
        {
            Console.WriteLine("子系统方法一");
        }
    }

    class SubSystemTwo
    {
        public void MethodTwo()
        {
            Console.WriteLine("子系统方法二");
        }
    }

    class SubSystemThree
    {
        public void MethodThree()
        {
            Console.WriteLine("子系统方法三");
        }
    }

    class SubSystemFour
    {
        public void MethodFour()
        {
            Console.WriteLine("子系统方法四");
        }
    }

    //外观类
    class Facade
    {
        SubSystemOne one;
        SubSystemTwo two;
        SubSystemThree three;
        SubSystemFour four;

        public Facade()
        {
            one = new SubSystemOne();
            two = new SubSystemTwo();
            three = new SubSystemThree();
            four = new SubSystemFour();
        }

        public void MethodA()
        {
            Console.WriteLine("\n方法组A()------");
            one.MethodOne();
            two.MethodTwo();
            four.MethodFour();
        }

        public void MethodB()
        {
            Console.WriteLine("\n方法组B()------");
            two.MethodTwo();
            three.MethodThree();
        }
    }
    class Program
    {
        static void Main(string[] args)
        {
            Facade facade = new Facade();

            facade.MethodA();
            facade.MethodB();

            Console.Read();
        }
    }
}

Facade模式优缺点

一、优点

• 屏蔽了外部客户端和系统内部模块的交互
• Facade的功能可以被多个客户端调用，可以实现复用（功能的共享）
• 对使用Facade的人员来说，Facade大大的节省了他们的学习成本。

二、缺点
不符合开闭原则。

本质

封装交互、简化调用。

迪米特法则

迪米特法则（Law of Demeter 或简写LoD）又叫最少知识原则（Least Knowledge Principle或简写为LKP）
如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
最少知识原则告诉我们要减少对象之间的交互，只留下几个“密友”。