1、外观模式（Facade Pattern) 动机(Motivate):在软件开发系统中，客户程序经常会与复杂系统的内部子系统之间产生耦合，而导致客户程序随着子系统的变化而变化。那么如何简化客户程序与子系统之间的交互接口？如何将复杂系统的内部子系统与客户程序之间的依赖解耦？意图(Intent):为子系统中的一组接口提供一个一致的界面，Facade 模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。-设计模式GOF结构图(Struct):适用性：1为一个复杂子系统提供一个简单接口。2提高子系统的独立性。3在层次化结构中，可以使用 Facade 模式定义系统中每一层的入口。生活中的例子：代码
2、实现：我们平时的开发中其实已经不知不觉的在用 Faade 模式，现在来考虑这样一个抵押系统，当有一个客户来时，有如下几件事情需要确认：到银行子系统查询他是否有足够多的存款，到信用子系统查询他是否有良好的信用，到贷款子系统查询他有无贷款劣迹。只有这三个子系统都通过时才可进行抵押。我们先不考虑 Faade 模式，那么客户程序就要直接访问这些子系统，分别进行判断。类结构图下： 在这个程序中，我们首先要有一个顾客类，它是一个纯数据类，并无任何操作，示意代码：1 /顾客类2 public class Customer3 4 private string _name;5 6 public Customer
3、(string name)7 8 this._name = name;9 10 11 public string Name12 13 get return _name; 14 15 下面这三个类均是子系统类，示意代码：1 /银行子系统2 public class Bank3 4 public bool HasSufficientSavings(Customer c, int amount)5 6 Console.WriteLine(“Check bank for “ + c.Name);7 return true;8 9 10 11 /信用子系统12 public class Credit13
4、 14 public bool HasGoodCredit(Customer c)15 16 Console.WriteLine(“Check credit for “ + c.Name);17 return true;18 19 20 21 /贷款子系统22 public class Loan23 24 public bool HasNoBadLoans(Customer c)25 26 Console.WriteLine(“Check loans for “ + c.Name);27 return true;28 29 看客户程序的调用：1 /客户程序2 public class Main
5、App3 4 private const int _amount = 12000;5 6 public static void Main()7 8 Bank bank = new Bank();9 Loan loan = new Loan();10 Credit credit = new Credit();11 12 Customer customer = new Customer(“Ann McKinsey“);13 14 bool eligible = true;15 16 if (!bank.HasSufficientSavings(customer, _amount)17 18 eli
6、gible = false;19 20 else if (!loan.HasNoBadLoans(customer)21 22 eligible = false;23 24 else if (!credit.HasGoodCredit(customer)25 26 eligible = false;27 28 29 Console.WriteLine(“n“ + customer.Name + “ has been “ + (eligible ? “Approved“ : “Rejected“);30 Console.ReadLine();31 32 可以看到，在不用 Faade 模式的情况下
7、，客户程序与三个子系统都发生了耦合，这种耦合使得客户程序依赖于子系统，当子系统化时，客户程序也将面临很多变化的挑战。一个合情合理的设计就是为这些子系统创建一个统一的接口，这个接口简化了客户程序的判断操作。看一下引入 Faade 模式后的类结构图：变外观类 Mortage 的实现如下：1 /外观类2 public class Mortgage3 4 private Bank bank = new Bank();5 private Loan loan = new Loan();6 private Credit credit = new Credit();7 8 public bool IsElig
8、ible(Customer cust, int amount)9 10 Console.WriteLine(“0 applies for 1:C loann“,11 cust.Name, amount);12 13 bool eligible = true;14 15 if (!bank.HasSufficientSavings(cust, amount)16 17 eligible = false;18 19 else if (!loan.HasNoBadLoans(cust)20 21 eligible = false;22 23 else if (!credit.HasGoodCredi
9、t(cust)24 25 eligible = false;26 27 28 return eligible;29 30 顾客类和子系统类的实现仍然如下：1 /银行子系统2 public class Bank3 4 public bool HasSufficientSavings(Customer c, int amount)5 6 Console.WriteLine(“Check bank for “ + c.Name);7 return true;8 9 10 11 /信用证子系统12 public class Credit13 14 public bool HasGoodCredit(C
10、ustomer c)15 16 Console.WriteLine(“Check credit for “ + c.Name);17 return true;18 19 20 21 /贷款子系统22 public class Loan23 24 public bool HasNoBadLoans(Customer c)25 26 Console.WriteLine(“Check loans for “ + c.Name);27 return true;28 29 30 31 /顾客类32 public class Customer33 34 private string name;35 36
11、public Customer(string name)37 38 this.name = name;39 40 41 public string Name42 43 get return name; 44 45 而此时客户程序的实现：1 /客户程序类2 public class MainApp3 4 public static void Main()5 6 /外观7 Mortgage mortgage = new Mortgage();8 9 Customer customer = new Customer(“Ann McKinsey“);10 bool eligable = mortgag
12、e.IsEligible(customer, 125000);11 12 Console.WriteLine(“n“ + customer.Name +13 “ has been “ + (eligable ? “Approved“ : “Rejected“); 14 Console.ReadLine();15 16 可以看到引入 Faade 模式后，客户程序只与 Mortgage 发生依赖，也就是 Mortgage 屏蔽了子系统之间的复杂的操作，达到了解耦内部子系统与客户程序之间的依赖。.NET 架构中的 Faade 模式Faade 模式在实际开发中最多的运用当属开发 N 层架构的应用程序了
13、，一个典型的 N 层结构如下：在这个架构中，总共分为四个逻辑层，分别为：用户层 UI，业务外观层 Business Faade，业务规则层 Business Rule，数据访问层 Data Access。其中 Business Faade 层的职责如下： 从“用户”层接收用户输入 如果请求需要对数据进行只读访问，则可能使用“数据访问”层 将请求传递到“业务规则”层 将响应从“业务规则”层返回到“用户”层 在对“业务规则”层的调用之间维护临时状态对这一架构最好的体现就是 Duwamish 示例了。在该应用程序中，有部分操作只是简单的从数据库根据条件提取数据，不需要经过任何处理，而直接将数据显示到
14、网页上，比如查询某类别的图书列表。而另外一些操作，比如计算定单中图书的总价并根据顾客的级别计算回扣等等，这部分往往有许多不同的功能的类，操作起来也比较复杂。如果采用传统的三层结构，这些商业逻辑一般是会放在中间层，那么对内部的这些大量种类繁多，使用方法也各异的不同的类的调用任务，就完全落到了表示层。这样势必会增加表示层的代码量，将表示层的任务复杂化，和表示层只负责接受用户的输入并返回结果的任务不太相称，并增加了层与层之间的耦合程度。于是就引入了一个 Faade 层，让这个 Facade 来负责管理系统内部类的调用，并为表示层提供了一个单一而简单的接口。看一下 Duwamish 结构图： 从图中可
15、以看到，UI 层将请求发送给业务外观层，业务外观层对请求进行初步的处理，判断是否需要调用业务规则层，还是直接调用数据访问层获取数据。最后由数据访问层访问数据库并按照来时的步骤返回结果到 UI 层，来看具体的代码实现。在获取商品目录的时候，Web UI 调用业务外观层：1 productSystem = new ProductSystem();2 categorySet = productSystem.GetCategories(categoryID);业务外观层直接调用了数据访问层：1 public CategoryData GetCategories(int categoryId)2 3 /
16、4 / Check preconditions5 /6 ApplicationAssert.CheckCondition(categoryId = 0,“Invalid Category Id“,ApplicationAssert.LineNumber);7 /8 / Retrieve the data9 /10 using (Categories accessCategories = new Categories()11 12 return accessCategories.GetCategories(categoryId);13 14 15 在添加订单时，UI 调用业务外观层：1 publ
17、ic void AddOrder()2 3 ApplicationAssert.CheckCondition(cartOrderData != null, “Order requires data“, ApplicationAssert.LineNumber);4 5 /Write trace log.6 ApplicationLog.WriteTrace(“Duwamish7.Web.Cart.AddOrder:rnCustomerId:“ +7 cartOrderData.TablesOrderData.CUSTOMER_TABLE.Rows0OrderData.PKID_FIELD.To
18、String();8 cartOrderData = (new OrderSystem().AddOrder(cartOrderData);9 业务外观层调用业务规则层：1 public OrderData AddOrder(OrderData order)2 3 /4 / Check preconditions5 /6 ApplicationAssert.CheckCondition(order != null, “Order is required“, ApplicationAssert.LineNumber);7 8 (new BusinessRules.Order().InsertOr
19、der(order);9 return order;10 业务规则层进行复杂的逻辑处理后，再调用数据访问层：1 public OrderData AddOrder(OrderData order)2 3 /4 / Check preconditions5 /6 ApplicationAssert.CheckCondition(order != null, “Order is required“, ApplicationAssert.LineNumber);7 8 (new BusinessRules.Order().InsertOrder(order);9 return order;10 11
20、 12 13 业务规则层进行复杂的逻辑处理后，再调用数据访问层：14 public bool InsertOrder(OrderData order)15 16 /17 / Assume its good18 /19 bool isValid = true;20 / 21 / Validate order summary22 /23 DataRow summaryRow = order.TablesOrderData.ORDER_SUMMARY_TABLE.Rows0;24 25 summaryRow.ClearErrors();26 27 if (CalculateShipping(orde
21、r) != (Decimal)(summaryRowOrderData.SHIPPING_HANDLING_FIELD)28 29 summaryRow.SetColumnError(OrderData.SHIPPING_HANDLING_FIELD, OrderData.INVALID_FIELD);30 isValid = false;31 32 33 if (CalculateTax(order) != (Decimal)(summaryRowOrderData.TAX_FIELD)34 35 summaryRow.SetColumnError(OrderData.TAX_FIELD,
22、OrderData.INVALID_FIELD);36 isValid = false;37 38 / 39 / Validate shipping info40 /41 isValid 42 /43 / Validate payment info 44 /45 DataRow paymentRow = order.TablesOrderData.PAYMENT_TABLE.Rows0;46 47 paymentRow.ClearErrors();48 49 isValid 50 isValid 51 isValid 52 isValid 53 isValid 54 /55 / Validat
23、e the order items and recalculate the subtotal56 /57 DataRowCollection itemRows = order.TablesOrderData.ORDER_ITEMS_TABLE.Rows;58 59 Decimal subTotal = 0;60 61 foreach (DataRow itemRow in itemRows)62 63 itemRow.ClearErrors();64 65 subTotal += (Decimal)(itemRowOrderData.EXTENDED_FIELD);66 67 if (Deci
24、mal)(itemRowOrderData.PRICE_FIELD) 0;93 94 95 else96 return false;97 Facade 模式的个要点：从客户程序的角度来看， Facade 模式不仅简化了整个组件系统的接口，同时对于组件内部与外部客户程序来说，从某种程度上也达到了一种“解耦”的效果-内部子系统的任何变化不会影响到 Facade 接口的变化。Facade 设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Facdae 很多时候更是一种架构设计模式。注意区分 Facade 模式、Adapter 模式、Bridge 模式与 Decorator 模式。Facade 模式注重简化接口，Adapter 模式注重转换接口，Bridge 模式注重分离接口（抽象）与其实现，Decorator 模式注重稳定接口的前提下为对象扩展功能。
