动机(Motivate):
在软件开发系统中,客户程序经常会与复杂系统的内部子系统之间产生耦合,而导致客户程序随着子系统的变化而变化。那么如何简化客户程序与子系统之间的交互接口?如何将复杂系统的内部子系统与客户程序之间的依赖解耦?
意图(Intent):
为子系统中的一组接口提供一个一致的界面, Facade 模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。
--------《设计模式》GOF
结构图(Struct):
适用性:
3 .在层次化结构中,可以使用 Facade 模式定义系统中每一层的入口。
生活中的例子:
代码实现:
我们平时的开发中其实已经不知不觉的在用 Façade 模式,现在来考虑这样一个抵押系统,当有一个客户来时,有如下几件事情需要确认:到银行子系统查询他是否有足够多的存款,到信用子系统查询他是否有良好的信用,到贷款子系统查询他有无贷款劣迹。只有这三个子系统都通过时才可进行抵押。我们先不考虑 Façade 模式,那么客户程序就要直接访问这些子系统,分别进行判断。类结构图下:
在这个程序中,我们首先要有一个顾客类,它是一个纯数据类,并无任何操作,示意代码:
2 public class Customer
3 {
4 private string _name;
5
6 public Customer( string name)
7 {
8 this ._name = name;
9 }
10
11 public string Name
12 {
13 get { return _name; }
14 }
15 }
下面这三个类均是子系统类,示意代码:
2 public class Bank
3 {
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 Credit
13 {
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 Loan
23 {
24 public bool HasNoBadLoans(Customer c)
25 {
26 Console.WriteLine( " Check loans for " + c.Name);
27 return true ;
28 }
29 }
看客户程序的调用:
2 public class MainApp
3 {
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 eligible = 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 }
可以看到,在不用Façade 模式的情况下,客户程序与三个子系统都发生了耦合,这种耦合使得客户程序依赖于子系统,当子系统 化时,客户程序也将面临很多变化的挑战。一个合情合理的设计就是为这些子系统创建一个统一的接口,这个接口简化了客户程序的判断操作。看一下引入 Façade 模式后的类结构图:
变
外观类 Mortage 的实现如下:
2 public class Mortgage
3 {
4 private Bank bank = new Bank();
5 private Loan loan = new Loan();
6 private Credit credit = new Credit();
7
8 public bool IsEligible(Customer cust, int amount)
9 {
10 Console.WriteLine( " {0} applies for {1:C} loan/n " ,
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.HasGoodCredit(cust))
24 {
25 eligible = false ;
26 }
27
28 return eligible;
29 }
30 }
顾客类和子系统类的实现仍然如下:
2 public class Bank
3 {
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 Credit
13 {
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 Loan
23 {
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 Customer
33 {
34 private string name;
35
36 public Customer( string name)
37 {
38 this .name = name;
39 }
40
41 public string Name
42 {
43 get { return name; }
44 }
45 }
而此时客户程序的实现:
2 public class MainApp
3 {
4 public static void Main()
5 {
6 // 外观
7 Mortgage mortgage = new Mortgage();
8
9 Customer customer = new Customer( " Ann McKinsey " );
10 bool eligable = mortgage.IsEligible(customer, 125000 );
11
12 Console.WriteLine( " /n " + customer.Name +
13 " has been " + (eligable ? " Approved " : " Rejected " ));
14 Console.ReadLine();
15 }
16 }
可以看到引入Façade 模式后,客户程序只与 Mortgage 发生依赖,也就是 Mortgage 屏蔽了子系统之间的复杂的操作,达到了解耦内部子系统与客户程序之间的依赖。
![](https://i-blog.csdnimg.cn/blog_migrate/ec59bd7c61e84429b782c84805c4e16f.jpeg)
对这一架构最好的体现就是 Duwamish 示 例了。在该应用程序中,有部分操作只是简单的从数据库根据条件提取数据,不需要经过任何处理,而直接将数据显示到网页上,比如查询某类别的图书列表。而另 外一些操作,比如计算定单中图书的总价并根据顾客的级别计算回扣等等,这部分往往有许多不同的功能的类,操作起来也比较复杂。如果采用传统的三层结构,这 些商业逻辑一般是会放在中间层,那么对内部的这些大量种类繁多,使用方法也各异的不同的类的调用任务,就完全落到了表示层。这样势必会增加表示层的代码 量,将表示层的任务复杂化,和表示层只负责接受用户的输入并返回结果的任务不太相称,并增加了层与层之间的耦合程度。于是就引入了一个 Façade 层,让这个 Facade 来负责管理系统内部类的调用,并为表示层提供了一个单一 而简单的接口。看一下Duwamish结构图:
在获取商品目录的时候, Web UI 调用业务外观层:
2 categorySet = productSystem.GetCategories(categoryID);
业务外观层直接调用了数据访问层:
2 {
3 //
4 // Check preconditions
5 //
6 ApplicationAssert.CheckCondition(categoryId >= 0 , " Invalid Category Id " ,ApplicationAssert.LineNumber);
7 //
8 // Retrieve the data
9 //
10 using (Categories accessCategories = new Categories())
11 {
12 return accessCategories.GetCategories(categoryId);
13 }
14
15 }
在添加订单时,UI调用业务外观层:
2 {
3 ApplicationAssert.CheckCondition(cartOrderData != null , " Order requires data " , ApplicationAssert.LineNumber);
4
5 // Write trace log.
6 ApplicationLog.WriteTrace( " Duwamish7.Web.Cart.AddOrder:/r/nCustomerId: " +
7 cartOrderData.Tables[OrderData.CUSTOMER_TABLE].Rows[ 0 ][OrderData.PKID_FIELD].ToString());
8 cartOrderData = ( new OrderSystem()).AddOrder(cartOrderData);
9 }
业务外观层调用业务规则层:
2 {
3 //
4 // Check preconditions
5 //
6 ApplicationAssert.CheckCondition(order != null , " Order is required " , ApplicationAssert.LineNumber);
7
8 ( new BusinessRules.Order()).InsertOrder(order);
9 return order;
10 }
业务规则层进行复杂的逻辑处理后,再调用数据访问层:
2 {
3 //
4 // Check preconditions
5 //
6 ApplicationAssert.CheckCondition(order != null , " Order is required " , ApplicationAssert.LineNumber);
7
8 ( new BusinessRules.Order()).InsertOrder(order);
9 return order;
10 }
11
12
13 业务规则层进行复杂的逻辑处理后,再调用数据访问层:
14 public bool InsertOrder(OrderData order)
15 {
16 //
17 // Assume it's good
18 //
19 bool isValid = true ;
20 //
21 // Validate order summary
22 //
23 DataRow summaryRow = order.Tables[OrderData.ORDER_SUMMARY_TABLE].Rows[ 0 ];
24
25 summaryRow.ClearErrors();
26
27 if (CalculateShipping(order) != (Decimal)(summaryRow[OrderData.SHIPPING_HANDLING_FIELD]))
28 {
29 summaryRow.SetColumnError(OrderData.SHIPPING_HANDLING_FIELD, OrderData.INVALID_FIELD);
30 isValid = false ;
31 }
32
33 if (CalculateTax(order) != (Decimal)(summaryRow[OrderData.TAX_FIELD]))
34 {
35 summaryRow.SetColumnError(OrderData.TAX_FIELD, OrderData.INVALID_FIELD);
36 isValid = false ;
37 }
38 //
39 // Validate shipping info
40 //
41 isValid &= IsValidField(order, OrderData.SHIPPING_ADDRESS_TABLE, OrderData.SHIP_TO_NAME_FIELD, 40 );
42 //
43 // Validate payment info
44 //
45 DataRow paymentRow = order.Tables[OrderData.PAYMENT_TABLE].Rows[ 0 ];
46
47 paymentRow.ClearErrors();
48
49 isValid &= IsValidField(paymentRow, OrderData.CREDIT_CARD_TYPE_FIELD, 40 );
50 isValid &= IsValidField(paymentRow, OrderData.CREDIT_CARD_NUMBER_FIELD, 32 );
51 isValid &= IsValidField(paymentRow, OrderData.EXPIRATION_DATE_FIELD, 30 );
52 isValid &= IsValidField(paymentRow, OrderData.NAME_ON_CARD_FIELD, 40 );
53 isValid &= IsValidField(paymentRow, OrderData.BILLING_ADDRESS_FIELD, 255 );
54 //
55 // Validate the order items and recalculate the subtotal
56 //
57 DataRowCollection itemRows = order.Tables[OrderData.ORDER_ITEMS_TABLE].Rows;
58
59 Decimal subTotal = 0 ;
60
61 foreach (DataRow itemRow in itemRows)
62 {
63 itemRow.ClearErrors();
64
65 subTotal += (Decimal)(itemRow[OrderData.EXTENDED_FIELD]);
66
67 if ((Decimal)(itemRow[OrderData.PRICE_FIELD]) <= 0 )
68 {
69 itemRow.SetColumnError(OrderData.PRICE_FIELD, OrderData.INVALID_FIELD);
70 isValid = false ;
71 }
72
73 if (( short )(itemRow[OrderData.QUANTITY_FIELD]) <= 0 )
74 {
75 itemRow.SetColumnError(OrderData.QUANTITY_FIELD, OrderData.INVALID_FIELD);
76 isValid = false ;
77 }
78 }
79 //
80 // Verify the subtotal
81 //
82 if (subTotal != (Decimal)(summaryRow[OrderData.SUB_TOTAL_FIELD]))
83 {
84 summaryRow.SetColumnError(OrderData.SUB_TOTAL_FIELD, OrderData.INVALID_FIELD);
85 isValid = false ;
86 }
87
88 if ( isValid )
89 {
90 using (DataAccess.Orders ordersDataAccess = new DataAccess.Orders())
91 {
92 return (ordersDataAccess.InsertOrderDetail(order)) > 0 ;
93 }
94 }
95 else
96 return false ;
97 }
Facade模式的个要点:
从客户程序的角度来看,Facade模式不仅简化了整个组件系统的接口,同时对于组件内部与外部客户程序来说,从某种程度上也达到了一种“解耦”的效果----内部子系统的任何变化不会影响到Facade接口的变化。
Facade设计模式更注重从架构的层次去看整个系统,而不是单个类的层次。Facdae很多时候更是一种架构
设计模式。
注意区分Facade模式、Adapter模式、Bridge模式与Decorator模式。Facade模式注重简化接口,Adapter模式注重转换 接口,Bridge模式注重分离接口(抽象)与其实现,Decorator模式注重稳定接口的前提下为对象扩展功能。