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

系统 2026 0
——.NET设计模式系列之十二
Terrylee 2006 3
概述
在软件开发系统中,客户程序经常会与复杂系统的内部子系统之间产生耦合,而导致客户程序随着子系统的变化而变化。那么如何简化客户程序与子系统之间的交互接口?如何将复杂系统的内部子系统与客户程序之间的依赖解耦?这就是要说的 Façade 模式。

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

示意图
门面模式没有一个一般化的类图描述,下面是一个示意性的对象图:
1 Façade 模式示意性对象图
生活中的例子
外观模式为子系统中的接口定义了一个统一的更高层次的界面,以便于使用。当消费者按照目录采购时,则体现了一个外观模式。消费者拨打一个号码与客服代表联系,客服代表则扮演了这个 " 外观 " ,他包含了与订货部、收银部和送货部的接口。
2 使用电话订货例子的外观模式对象图
Facade 模式解说
我们平时的开发中其实已经不知不觉的在用 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(Customerc, int amount)
{
Console.WriteLine(
" Checkbankfor " + c.Name);
return true ;
}

}


// 信用子系统
public class Credit
{
public bool HasGoodCredit(Customerc)
{
Console.WriteLine(
" Checkcreditfor " + c.Name);
return true ;
}

}


// 贷款子系统
public class Loan
{
public bool HasNoBadLoans(Customerc)
{
Console.WriteLine(
" Checkloansfor " + c.Name);
return true ;
}

}

来看客户程序的调用:

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

public static void Main()
{
Bankbank
= new Bank();
Loanloan
= new Loan();
Creditcredit
= new Credit();

Customercustomer
= new Customer( " AnnMcKinsey " );

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 + " hasbeen " + (eligible ? " Approved " : " Rejected " ));
Console.ReadLine();
}

}

可以看到,在不用
4
门面类 Mortage 的实现如下:
// 外观类
public class Mortgage
{
private Bankbank = new Bank();
private Loanloan = new Loan();
private Creditcredit = new Credit();

public bool IsEligible(Customercust, int amount)
{
Console.WriteLine(
" {0}appliesfor{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(Customerc, int amount)
{
Console.WriteLine(
" Checkbankfor " + c.Name);
return true ;
}

}


// 信用证子系统
public class Credit
{
public bool HasGoodCredit(Customerc)
{
Console.WriteLine(
" Checkcreditfor " + c.Name);
return true ;
}

}


// 贷款子系统
public class Loan
{
public bool HasNoBadLoans(Customerc)
{
Console.WriteLine(
" Checkloansfor " + 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()
{
// 外观
Mortgagemortgage = new Mortgage();

Customercustomer
= new Customer( " AnnMcKinsey " );
bool eligable = mortgage.IsEligible(customer, 125000 );

Console.WriteLine(
" /n " + customer.Name +
" hasbeen " + (eligable ? " Approved " : " Rejected " ));
Console.ReadLine();
}

}

可以看到引入
.NET 架构中的 Façade 模式
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 CategoryDataGetCategories( int categoryId)
{
//
// Checkpreconditions
//
ApplicationAssert.CheckCondition(categoryId >= 0 , " InvalidCategoryId " ,ApplicationAssert.LineNumber);
//
// Retrievethedata
//
using (CategoriesaccessCategories = new Categories())
{
return accessCategories.GetCategories(categoryId);
}


}

在添加订单时,UI调用业务外观层:

public void AddOrder()
{
ApplicationAssert.CheckCondition(cartOrderData
!= null , " Orderrequiresdata " ,ApplicationAssert.LineNumber);

// Writetracelog.
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 OrderDataAddOrder(OrderDataorder)
{
//
// Checkpreconditions
//
ApplicationAssert.CheckCondition(order != null , " Orderisrequired " ,ApplicationAssert.LineNumber);

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

业务规则层进行复杂的逻辑处理后,再调用数据访问层:
public bool InsertOrder(OrderDataorder)
{
//
// Assumeit'sgood
//
bool isValid = true ;
//
// Validateordersummary
//
DataRowsummaryRow = 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 ;
}

//
// Validateshippinginfo
//
isValid &= IsValidField(order,OrderData.SHIPPING_ADDRESS_TABLE,OrderData.SHIP_TO_NAME_FIELD, 40 );
//
// Validatepaymentinfo
//
DataRowpaymentRow = 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 );
//
// Validatetheorderitemsandrecalculatethesubtotal
//
DataRowCollectionitemRows = order.Tables[OrderData.ORDER_ITEMS_TABLE].Rows;

DecimalsubTotal
= 0 ;

foreach (DataRowitemRow 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 ;
}

}

//
// Verifythesubtotal
//
if (subTotal != (Decimal)(summaryRow[OrderData.SUB_TOTAL_FIELD]))
{
summaryRow.SetColumnError(OrderData.SUB_TOTAL_FIELD,OrderData.INVALID_FIELD);
isValid
= false ;
}


if (isValid)
{
using (DataAccess.OrdersordersDataAccess = new DataAccess.Orders())
{
return (ordersDataAccess.InsertOrderDetail(order)) > 0 ;
}

}

else
return false ;
}
[MSDN]

效果及实现要点
1 Façade 模式对客户屏蔽了子系统组件,因而减少了客户处理的对象的数目并使得子系统使用起来更加方便。
2 Façade 模式实现了子系统与客户之间的松耦合关系,而子系统内部的功能组件往往是紧耦合的。松耦合关系使得子系统的组件变化不会影响到它的客户。
3 .如果应用需要,它并不限制它们使用子系统类。因此你可以在系统易用性与通用性之间选择。

适用性
1 .为一个复杂子系统提供一个简单接口。
2 .提高子系统的独立性。
3 .在层次化结构中,可以使用 Facade 模式定义系统中每一层的入口。

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

参考资料
Erich Gamma 等,《设计模式:可复用面向对象软件的基础》,机械工业出版社
Robert C.Martin ,《敏捷软件开发:原则、模式与实践》,清华大学出版社
阎宏,《 Java 与模式》,电子工业出版社
Alan Shalloway James R. Trott ,《 Design Patterns Explained 》,中国电力出版社
MSDN WebCast C# 面向对象设计模式纵横谈 (11) Facade 外观模式 ( 结构型模式 )

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


更多文章、技术交流、商务合作、联系博主

微信扫码或搜索:z360901061

微信扫一扫加我为好友

QQ号联系: 360901061

您的支持是博主写作最大的动力,如果您喜欢我的文章,感觉我的文章对您有帮助,请用微信扫描下面二维码支持博主2元、5元、10元、20元等您想捐的金额吧,狠狠点击下面给点支持吧,站长非常感激您!手机微信长按不能支付解决办法:请将微信支付二维码保存到相册,切换到微信,然后点击微信右上角扫一扫功能,选择支付二维码完成支付。

【本文对您有帮助就好】

您的支持是博主写作最大的动力,如果您喜欢我的文章,感觉我的文章对您有帮助,请用微信扫描上面二维码支持博主2元、5元、10元、自定义金额等您想捐的金额吧,站长会非常 感谢您的哦!!!

发表我的评论
最新评论 总共0条评论