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

2、  模型

public class ModularA      {          public void ModularAMethod()          {              Console.WriteLine("A模块的方法。");          }      }        public class ModularB      {            public void ModularBMethod()          {              Console.WriteLine("B模块的方法。");          }      }        public class ModularC      {          public void ModularCMethod()          {              Console.WriteLine("C模块的方法。");          }      }          public class FaCade      {          private ModularA mda;            private ModularB mdb;            private ModularC mdc;             public FaCade()          {              mda = new ModularA();                mdb = new ModularB();                mdc = new ModularC();          }            public void FaCadeMethod()//该方法负责对外的联系          {              mda.ModularAMethod();                mdb.ModularBMethod();                mdc.ModularCMethod();          }      }

客户端

//如果不用外观模式，则客户端分别要调用ModularA，ModularB,ModularC，耦合就强了。  //ModularA mda = new ModularA();  //ModularB mdb = new ModularB();  //ModularC mdc = new ModularC();  //mda.ModularAMethod();  //mdb.ModularBMethod();  //mdc.ModularCMethod();     //使用外观模式，客户端只关心FaCade的方法，之和这一个类发生联系，减少了耦合。  FaCade fd = new FaCade();  fd.FaCadeMethod();  Console.ReadLine();

 结果

    其实这种模式，在平时写代码时那是经常使用的，有时候写一个单独的功能模块，就有这样的一个类，负责与外界交流，接受传入的参数，并负责传出结果，外部是不需要关心模块如何实现，往往是引用这个类传入某些值，该类再传出结果，至于如何实现功能那就是这个模块的事了。因此减少了这个模块与外界的接触，而且如果该模块的内部算法除了问题，不会影响其他模块运行，只是表现在结果不正确而已。而且我一般写单独模块都把里面的public除了要和外界交互的类，其它都写成internal，强制外面访问不到内部的细节。