(第Ⅲ部分 结构型模式篇) 第11章 外观模式（Façade Pattern）

概述



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



意图


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

示意图


门面模式没有一个一般化的类图描述，下面是一个示意性的对象图：



图
1 Façade
模式示意性对象图

生活中的例子


外观模式为子系统中的接口定义了一个统一的更高层次的界面，以便于使用。当消费者按照目录采购时，则体现了一个外观模式。消费者拨打一个号码与客服代表联系，客服代表则扮演了这个
"
外观
"
，他包含了与订货部、收银部和送货部的接口。



图
2
使用电话订货例子的外观模式对象图


[b]Facade

模式解说


[/b]

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



图
3

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



//
顾客类



public
class
Customer







{



private
string
_name;





public
Customer(
string
name)







{



this
._name
=
name;



}





public
string
Name







{





get



{
return
_name; }



}



}

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



//
银行子系统



public
class
Bank







{



public
bool
HasSufficientSavings(Customer c,
int
amount)







{



Console.WriteLine(
"
Check bank for
"
+
c.Name);



return
true
;



}



}





//
信用子系统



public
class
Credit







{



public
bool
HasGoodCredit(Customer c)







{



Console.WriteLine(
"
Check credit for
"
+
c.Name);



return
true
;



}



}





//
贷款子系统



public
class
Loan







{



public
bool
HasNoBadLoans(Customer c)







{



Console.WriteLine(
"
Check loans for
"
+
c.Name);



return
true
;



}



}

来看客户程序的调用：

Façade
模式的情况下，客户程序与三个子系统都发生了耦合，这种耦合使得客户程序依赖于子系统，当子系统变化时，客户程序也将面临很多变化的挑战。一个合情合理的设计就是为这些子系统创建一个统一的接口，这个接口简化了客户程序的判断操作。看一下引入
Façade
模式后的类结构图：



//
客户程序



public
class
MainApp







{



private
const
int
_amount
=
12000
;





public
static
void
Main()







{



Bank bank
=
new
Bank();



Loan loan
=
new
Loan();



Credit credit
=
new
Credit();





Customer customer
=
new
Customer(
"
Ann McKinsey
"
);





bool
eligible
=
true
;





if
(
!
bank.HasSufficientSavings(customer, _amount))







{



eligible
=
false
;



}



else
if
(
!
loan.HasNoBadLoans(customer))







{



eligible
=
false
;



}



else
if
(
!
credit.HasGoodCredit(customer))







{



eligible
=
false
;



}





Console.WriteLine(
"
/n
"
+
customer.Name
+
"
has been
"
+
(eligible
?
"
Approved
"
:
"
Rejected
"
));



Console.ReadLine();



}



}

可以看到，在不用



图
4

门面类
Mortage
的实现如下：



//
外观类



public
class
Mortgage







{



private
Bank bank
=
new
Bank();



private
Loan loan
=
new
Loan();



private
Credit credit
=
new
Credit();





public
bool
IsEligible(Customer cust,
int
amount)







{



Console.WriteLine(
"
{0} applies for {1:C} loan/n
"
,



cust.Name, amount);





bool
eligible
=
true
;





if
(
!
bank.HasSufficientSavings(cust, amount))







{



eligible
=
false
;



}



else
if
(
!
loan.HasNoBadLoans(cust))







{



eligible
=
false
;



}



else
if
(
!
credit.HasGoodCredit(cust))







{



eligible
=
false
;



}





return
eligible;



}



}

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



//
银行子系统



public
class
Bank







{



public
bool
HasSufficientSavings(Customer c,
int
amount)







{



Console.WriteLine(
"
Check bank for
"
+
c.Name);



return
true
;



}



}





//
信用证子系统



public
class
Credit







{



public
bool
HasGoodCredit(Customer c)







{



Console.WriteLine(
"
Check credit for
"
+
c.Name);



return
true
;



}



}





//
贷款子系统



public
class
Loan







{



public
bool
HasNoBadLoans(Customer c)







{



Console.WriteLine(
"
Check loans for
"
+
c.Name);



return
true
;



}



}





//
顾客类



public
class
Customer







{



private
string
name;





public
Customer(
string
name)







{



this
.name
=
name;



}





public
string
Name







{





get



{
return
name; }



}



}

而此时客户程序的实现：

Façade
模式后，客户程序只与
Mortgage
发生依赖，也就是
Mortgage
屏蔽了子系统之间的复杂的操作，达到了解耦内部子系统与客户程序之间的依赖。



//
客户程序类



public
class
MainApp







{



public
static
void
Main()







{



//
外观



Mortgage mortgage
=
new
Mortgage();





Customer customer
=
new
Customer(
"
Ann McKinsey
"
);



bool
eligable
=
mortgage.IsEligible(customer,
125000
);





Console.WriteLine(
"
/n
"
+
customer.Name
+



"
has been
"
+
(eligable
?
"
Approved
"
:
"
Rejected
"
));



Console.ReadLine();



}



}

可以看到引入


[b].NET

架构中的

Façade

模式


[/b]

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



图
5

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

l

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

l

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

l

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

l

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

l

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

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



图6

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

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



productSystem
=
new
ProductSystem();



categorySet
=
productSystem.GetCategories(categoryID);

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



public
CategoryData GetCategories(
int
categoryId)







{



//



//
Check preconditions



//



ApplicationAssert.CheckCondition(categoryId
>=
0
,
"
Invalid Category Id
"
,ApplicationAssert.LineNumber);



//



//
Retrieve the data



//



using
(Categories accessCategories
=
new
Categories())







{



return
accessCategories.GetCategories(categoryId);



}





}

在添加订单时，UI调用业务外观层：



public
void
AddOrder()







{



ApplicationAssert.CheckCondition(cartOrderData
!=
null
,
"
Order requires data
"
, ApplicationAssert.LineNumber);





//
Write trace log.



ApplicationLog.WriteTrace(
"
Duwamish7.Web.Cart.AddOrder:/r/nCustomerId:
"
+



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



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



}

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



public
OrderData AddOrder(OrderData order)







{



//



//
Check preconditions



//



ApplicationAssert.CheckCondition(order
!=
null
,
"
Order is required
"
, ApplicationAssert.LineNumber);





(
new
BusinessRules.Order()).InsertOrder(order);



return
order;



}

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



public
bool
InsertOrder(OrderData order)







{



//



//
Assume it's good



//



bool
isValid
=
true
;



//



//
Validate order summary



//



DataRow summaryRow
=
order.Tables[OrderData.ORDER_SUMMARY_TABLE].Rows[
0
];





summaryRow.ClearErrors();





if
(CalculateShipping(order)
!=
(Decimal)(summaryRow[OrderData.SHIPPING_HANDLING_FIELD]))







{



summaryRow.SetColumnError(OrderData.SHIPPING_HANDLING_FIELD, OrderData.INVALID_FIELD);



isValid
=
false
;



}





if
(CalculateTax(order)
!=
(Decimal)(summaryRow[OrderData.TAX_FIELD]))







{



summaryRow.SetColumnError(OrderData.TAX_FIELD, OrderData.INVALID_FIELD);



isValid
=
false
;



}



//



//
Validate shipping info



//



isValid
&=
IsValidField(order, OrderData.SHIPPING_ADDRESS_TABLE, OrderData.SHIP_TO_NAME_FIELD,
40
);



//



//
Validate payment info



//



DataRow paymentRow
=
order.Tables[OrderData.PAYMENT_TABLE].Rows[
0
];





paymentRow.ClearErrors();





isValid
&=
IsValidField(paymentRow, OrderData.CREDIT_CARD_TYPE_FIELD,
40
);



isValid
&=
IsValidField(paymentRow, OrderData.CREDIT_CARD_NUMBER_FIELD,
32
);



isValid
&=
IsValidField(paymentRow, OrderData.EXPIRATION_DATE_FIELD,
30
);



isValid
&=
IsValidField(paymentRow, OrderData.NAME_ON_CARD_FIELD,
40
);



isValid
&=
IsValidField(paymentRow, OrderData.BILLING_ADDRESS_FIELD,
255
);



//



//
Validate the order items and recalculate the subtotal



//



DataRowCollection itemRows
=
order.Tables[OrderData.ORDER_ITEMS_TABLE].Rows;





Decimal subTotal
=
0
;





foreach
(DataRow itemRow
in
itemRows)







{



itemRow.ClearErrors();





subTotal
+=
(Decimal)(itemRow[OrderData.EXTENDED_FIELD]);





if
((Decimal)(itemRow[OrderData.PRICE_FIELD])
<=
0
)







{



itemRow.SetColumnError(OrderData.PRICE_FIELD, OrderData.INVALID_FIELD);



isValid
=
false
;



}





if
((
short
)(itemRow[OrderData.QUANTITY_FIELD])
<=
0
)







{



itemRow.SetColumnError(OrderData.QUANTITY_FIELD, OrderData.INVALID_FIELD);



isValid
=
false
;



}



}



//



//
Verify the subtotal



//



if
(subTotal
!=
(Decimal)(summaryRow[OrderData.SUB_TOTAL_FIELD]))







{



summaryRow.SetColumnError(OrderData.SUB_TOTAL_FIELD, OrderData.INVALID_FIELD);



isValid
=
false
;



}





if
( isValid )







{



using
(DataAccess.Orders ordersDataAccess
=
new
DataAccess.Orders())







{



return
(ordersDataAccess.InsertOrderDetail(order))
>
0
;



}



}



else



return
false
;



}

[MSDN]


[b]效果及实现要点


[/b]

1
．
Façade
模式对客户屏蔽了子系统组件，因而减少了客户处理的对象的数目并使得子系统使用起来更加方便。

2
．
Façade
模式实现了子系统与客户之间的松耦合关系，而子系统内部的功能组件往往是紧耦合的。松耦合关系使得子系统的组件变化不会影响到它的客户。

3
．如果应用需要，它并不限制它们使用子系统类。因此你可以在系统易用性与通用性之间选择。


[b]适用性


[/b]

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

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

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


[b]总结


[/b]

Façade
模式注重的是简化接口，它更多的时候是从架构的层次去看整个系统，而并非单个类的层次。


[b]参考资料


[/b]

Erich Gamma
等，《设计模式：可复用面向对象软件的基础》，机械工业出版社

Robert C.Martin
，《敏捷软件开发：原则、模式与实践》，清华大学出版社

阎宏，《
Java
与模式》，电子工业出版社

Alan Shalloway James R. Trott
，《
Design Patterns Explained
》，中国电力出版社

MSDN WebCast
《
C#
面向对象设计模式纵横谈
(11)
：
Facade
外观模式
(
结构型模式
)
》