大话设计模式——外观模式（C++顾客抵押系统）

动机(Motivate):

在软件开发系统中，客户程序经常会与复杂系统的内部子系统之间产生耦合，而导致客户程序随着子系统的变化而变化。那么如何简化客户程序与子系统之间的交互接口？如何将复杂系统的内部子系统与客户程序之间的依赖解耦？

意图(Intent):

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

--------《设计模式》GOF

结构图(Struct):









适用性：

1 ．为一个复杂子系统提供一个简单接口。

2 ．提高子系统的独立性。

3 ．在层次化结构中，可以使用 Facade 模式定义系统中每一层的入口。

生活中的例子：





代码实现：

我们平时的开发中其实已经不知不觉的在用 Façade 模式，现在来考虑这样一个抵押系统，当有一个客户来时，有如下几件事情需要确认：到银行子系统查询他是否有足够多的存款，到信用子系统查询他是否有良好的信用，到贷款子系统查询他有无贷款劣迹。只有这三个子系统都通过时才可进行抵押。我们先不考虑 Façade 模式，那么客户程序就要直接访问这些子系统，分别进行判断。类结构图下：







在这个程序中，我们首先要有一个顾客类，它是一个纯数据类，并无任何操作，示意代码：

1 // 顾客类

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 }

下面这三个类均是子系统类，示意代码：

1 // 银行子系统

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 }

看客户程序的调用：

1 // 客户程序

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 的实现如下：

1 / 外观类

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 }

顾客类和子系统类的实现仍然如下：

1 // 银行子系统

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 }

而此时客户程序的实现：

1 // 客户程序类

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 屏蔽了子系统之间的复杂的操作，达到了解耦内部子系统与客户程序之间的依赖。



[b].NET 架构中的 Façade 模式[/b]

Façade 模式在实际开发中最多的运用当属开发 N 层架构的应用程序了，一个典型的 N 层结构如下：




在这个架构中，总共分为四个逻辑层，分别为：用户层 UI ，业务外观层 Business
Façade ，业务规则层 Business Rule，数据访问层 Data Access 。其中 Business
Façade 层的职责如下：

l 从“用户”层接收用户输入

l 如果请求需要对数据进行只读访问，则可能使用“数据访问”层

l 将请求传递到“业务规则”层

l 将响应从“业务规则”层返回到“用户”层

l 在对“业务规则”层的调用之间维护临时状态

对这一架构最好的体现就是 Duwamish 示 例了。在该应用程序中，有部分操作只是简单的从数据库根据条件提取数据，不需要经过任何处理，而直接将数据显示到网页上，比如查询某类别的图书列表。而另 外一些操作，比如计算定单中图书的总价并根据顾客的级别计算回扣等等，这部分往往有许多不同的功能的类，操作起来也比较复杂。如果采用传统的三层结构，这
些商业逻辑一般是会放在中间层，那么对内部的这些大量种类繁多，使用方法也各异的不同的类的调用任务，就完全落到了表示层。这样势必会增加表示层的代码 量，将表示层的任务复杂化，和表示层只负责接受用户的输入并返回结果的任务不太相称，并增加了层与层之间的耦合程度。于是就引入了一个 Façade 层，让这个 Facade 来负责管理系统内部类的调用，并为表示层提供了一个单一 而简单的接口。看一下Duwamish结构图：





从图中可以看到，UI层 将请求发送给业务外观层，业务外观层对请求进行初步的处理，判断是否需要调用业务规则层，还是直接调用数据访问层获取数据。最后由数据访问层访问数据库并按 照来时的步骤返回结果到 UI 层，来看具体的代码实现。

在获取商品目录的时候， Web UI 调用业务外观层：

1 productSystem = new ProductSystem();

2 categorySet = productSystem.GetCategories(categoryID);

业务外观层直接调用了数据访问层：

1 public CategoryData GetCategories( int 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调用业务外观层：

1 public 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:/r/nCustomerId: " +

7 cartOrderData.Tables[OrderData.CUSTOMER_TABLE].Rows[ 0 ][OrderData.PKID_FIELD].ToString());

8 cartOrderData = ( new OrderSystem()).AddOrder(cartOrderData);

9 }

业务外观层调用业务规则层：

1 public OrderData AddOrder(OrderData order)

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 }



业务规则层进行复杂的逻辑处理后，再调用数据访问层：

1 public OrderData AddOrder(OrderData order)

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模式注重稳定接口的前提下为对象扩展功能。