C#设计模式-外观模式(Facade Patten)

一、概述
Facade（外观）模式为子系统中的各类（或结构与方法）提供一个简明一致的界面，隐藏子系统的复杂性，使子系统更加容易使用。
实际应用中，我们在对付一些老旧的code（尤其是将C的代码转成C++代码）或者即便不是老旧code，但涉及多个子系统时，除了重写全部代码（对于老旧code而言），我们还可能采用这样一种策略：
重新进行类的设计，将原来分散在源码中的类/结构及方法重新组合，形成新的、统一的接口，供上层应用使用。
这在某种意义上与Adapter及Proxy有类似之处，但是，Proxy（代理）注重在为Client-Subject提供一个访问的中间层，如CORBA可为应用程序提供透明访问支持，使应用程序无需去考虑平台及网络造成的差异及其它诸多技术细节；Adapter（适配器）注重对接口的转换与调整；而Facade所面对的往往是多个类或其它程序单元，通过重新组合各类及程序单元，对外提供统一的接口/界面。
二、应用
在遇到以下情况使用Facade模式：
1、当你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性，也更容易对子系统进行定制，但这也给那些不需要定制子系统的用户带来一些使用上的困难。
Facade可以提供一个简单的缺省视图，这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过Facade层。
2、客户程序与抽象类的实现部分之间存在着很大的依赖性。引入Facade将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。
3、当你需要构建一个层次结构的子系统时，使用Facade模式定义子系统中每层的入口点，如果子系统之间是相互依赖的，你可以让它们仅通过Facade进行通讯，从而简化了它们之间的依赖关系。

三、优缺点
Facade模式有下面一些优点：
1、它对客户屏蔽子系统组件，因而减少了客户处理的对象的数目并使得子系统使用起来更加方便。
2、它实现了子系统与客户之间的松耦合关系，而子系统内部的功能组件往往是紧耦合的。
松耦合关系使得子系统的组件变化不会影响到它的客户。Facade模式有助于建立层次结构系统，也有助于对对象之间的依赖关系分层。Facade模式可以消除复杂的循环依赖关系。这一点在客户程序与子系统是分别实现的时候尤为重要。
在大型软件系统中降低编译依赖性至关重要。在子系统类改变时，希望尽量减少重编译工作以节省时间。用Facade可以降低编译依赖性，限制重要系统中较小的变化所需的重编译工作。Facade模式同样也有利于简化系统在不同平台之间的移植过程，因为编译一个子系统一般不需要编译所有其他的子系统。
3、如果应用需要，它并不限制它们使用子系统类。因此你可以在系统易用性和通用性之间加以选择。

//User

    #region User

 

    public class Customer

    {

        private string name;

 

        public Customer(string _name)

        {

            _name = name;

        }

 

        public string Name

        {

            get { return name; }

        }

    }

 

    #endregion

 

    //Sub System One

   #region Sub System One - Bank

 

    public class Bank

    {

        public String Saving(Customer c)

        {

            return "Check bank for " + c.Name;

        }

    }

 

    #endregion

 

    //Sub System Two

    #region Sub System Two - Credit

 

    public class Credit

    {

        public String GoodCredit(int amount, Customer c)

        {

            return "Check credit for " + c.Name + amount.ToString();

        }

    }

 

    #endregion

 

    //Sub System Three - Loan

    #region Sub System Three - Loan

 

    public class Loan

    {

        public String GoodLoan(Customer c)

        {

            return "Check loan for " + c.Name;

        }

    }

 

    #endregion

 

    //Facade Model

    public class FacadeApplication

    {

        private int amount;

        private Bank bank;

        private Loan loan;

        private Credit credit;

 

        public FacadeApplication(int amount)

        {

            this.amount = amount;

        }

 

        public bool isChecking(Customer c)

        {

            if (!bank.Saving(c))

            {

                return false;

            }

            if (!loan.GoodLoan(c))

            {

                return false;

            }

            if (!credit.GoodCredit(amount, c))

            {

                return false;

            }

            return true;

        }

    }

 

    class Program

    {

        static void Main(string[] args)

        {

            Customer customer = new Customer("BrainLei");

 

            //Credit Facade

            FacadeApplication facade = new FacadeApplication(10000);

 

            //Call subsystem through facade

            facade.isChecking(customer);

 

            return 0;

        }

}

 

在实际应用中，确实遇到业务逻辑比较复杂的情况。业务逻辑复杂的结果势必导致业务逻辑层极为复杂。复杂的业务逻辑层不仅仅本身由于过于复杂而容易出错。而且它的复杂性也会影响以后对业务逻辑层的修改和维护以及效率。微软duwamish示例代码便引入了facade思想来解决这么一个问题。
微软的做法是将业务逻辑层分开，分别建立facade层和rule层。由rule层来封装一些元素性的业务逻辑规则，而facade层则起到了一个视图和控制器的作用。来自web的请求不能直接访问rule层，而必须访问facade层，由facade层来根据请求决定是访问rule层还是数据层。实际上facade层就是在rule层的基础上抽象出来的一些业务逻辑比较固定，有具体表象的逻辑，象视图一样建立起来。当web层发出请求后，facade层首先判断请求的内容，如果自身能够处理就直接调用数据层。如果自身的业务逻辑不够，则访问rule层，由rule层来访问数据层。
实际上facade这种方法说白了就是在纵向上对一个复杂的系统进行抽象，抽象的结果就是使复杂系统模块化，从而降低每个模块的复杂度。当我想纵向抽象也许会有限制，有时候也许对一个系统无法进行足够的纵向抽象。可不可以对系统进行横向抽象，直接将业务逻辑层根据业务逻辑抽象为好几个模块，然后写一个总的业务逻辑调用层，直接调用业务逻辑的模块，从而实现抽象。