外观模式(Façade Pattern)
——.NET设计模式系列之十二
Terrylee,2006年3月
概述
在软件开发系统中,客户程序经常会与复杂系统的内部子系统之间产生耦合,而导致客户程序随着子系统的变化而变化。那么如何简化客户程序与子系统之间的交互接口?如何将复杂系统的内部子系统与客户程序之间的依赖解耦?这就是要说的Façade 模式。
意图
为子系统中的一组接口提供一个一致的界面,Facade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。[GOF 《设计模式》]
示意图
门面模式没有一个一般化的类图描述,下面是一个示意性的对象图:
图1 Façade模式示意性对象图
生活中的例子
外观模式为子系统中的接口定义了一个统一的更高层次的界面,以便于使用。当消费者按照目录采购时,则体现了一个外观模式。消费者拨打一个号码与客服代表联系,客服代表则扮演了这个"外观",他包含了与订货部、收银部和送货部的接口。
图2使用电话订货例子的外观模式对象图
Facade模式解说
我们平时的开发中其实已经不知不觉的在用Façade模式,现在来考虑这样一个抵押系统,当有一个客户来时,有如下几件事情需要确认:到银行子系统查询他是否有足够多的存款,到信用子系统查询他是否有良好的信用,到贷款子系统查询他有无贷款劣迹。只有这三个子系统都通过时才可进行抵押。我们先不考虑Façade模式,那么客户程序就要直接访问这些子系统,分别进行判断。类结构图下:
图3
在这个程序中,我们首先要有一个顾客类,它是一个纯数据类,并无任何操作,示意代码:
下面这三个类均是子系统类,示意代码:
来看客户程序的调用:
可以看到,在不用Façade模式的情况下,客户程序与三个子系统都发生了耦合,这种耦合使得客户程序依赖于子系统,当子系统变化时,客户程序也将面临很多变化的挑战。一个合情合理的设计就是为这些子系统创建一个统一的接口,这个接口简化了客户程序的判断操作。看一下引入Façade模式后的类结构图:
图4
门面类Mortage的实现如下:
顾客类和子系统类的实现仍然如下:
而此时客户程序的实现:
可以看到引入Façade模式后,客户程序只与Mortgage发生依赖,也就是Mortgage屏蔽了子系统之间的复杂的操作,达到了解耦内部子系统与客户程序之间的依赖。
.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=newProductSystem();
categorySet=productSystem.GetCategories(categoryID);
业务外观层直接调用了数据访问层:
publicCategoryDataGetCategories(intcategoryId)
{
//
//Checkpreconditions
//
ApplicationAssert.CheckCondition(categoryId>=0,"InvalidCategoryId",ApplicationAssert.LineNumber);
//
//Retrievethedata
//
using(CategoriesaccessCategories=newCategories())
{
returnaccessCategories.GetCategories(categoryId);
}
}
在添加订单时,UI调用业务外观层:
publicvoidAddOrder()
{
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=(newOrderSystem()).AddOrder(cartOrderData);
}
业务外观层调用业务规则层:
publicOrderDataAddOrder(OrderDataorder)
{
//
//Checkpreconditions
//
ApplicationAssert.CheckCondition(order!=null,"Orderisrequired",ApplicationAssert.LineNumber);
(newBusinessRules.Order()).InsertOrder(order);
returnorder;
}
业务规则层进行复杂的逻辑处理后,再调用数据访问层:
publicboolInsertOrder(OrderDataorder)
{
//
//Assumeit'sgood
//
boolisValid=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(DataRowitemRowinitemRows)
{
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=newDataAccess.Orders())
{
return(ordersDataAccess.InsertOrderDetail(order))>0;
}
}
else
returnfalse;
}
[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外观模式(结构型模式)》
相关推荐
我们先不考虑Façade模式,那么客户程序就要直接访问这3个子系统,分别进行判断。未采用外观模式的类结构图如下。 要求: 1、画出适合上述外观模式的类图 2、给出相关代码。用printf("")类似的方式表示相关的行为...
考虑这样一个抵押系统,当有一个客户来时,有如下几件事情需要确认:到银行子系统查询他是否有足够...我们先不考虑Façade模式,那么客户程序就要直接访问这些子系统,分别进行判断. 未采用外观模式的类结构图见附件。
• Chapter 6: The Façade Pattern • Chapter 7: The Adapter Pattern • Chapter 8: Expanding Our Horizons • Chapter 9: The Strategy Pattern • Chapter 10: The Bridge Pattern • Chapter 11: The ...
第 11 章 Proxy樣式, 237 11.1 Proxy樣式美何在? 11.2 介紹Proxy樣式 11.3 Android框架與Proxy樣式 第 12 章 Bridge樣式, 277 12.1 Bridge樣式美何在? 12.2 介紹Bridge樣式 12.3 Android框架與Bridge樣式 第 13 ...
15. Adapter、Bridge、Composite、Decorator、Façade、Flyweight、Proxy 16. Remote Façade 17. 行为型模式 18. Strategy、State、Template Method、Command、Chain of Responsibility、Observer、Mediator 19. ,...
UML应用场景1为一个复杂的子系统提供一个简单的接口2当客户端程序与抽象类的实现部分之间存在着很大的依赖时3在层次化结构中,使用Façade模式定义系统中每一层
外观模式属于结构型模式,其意图是为子系统中的一组接口提供一个一致的界面,Façade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。在项目设计中,把一个系统划分成为若干个子系统由利于降低系统的...
第 15 章 Façade 樣式, 343 15.1 Façade 樣式美何在? 15.2 介紹Façade 樣式 15.3 Android 框架與Façade 樣式 第 16 章 讓Android 框架之美 ---- Android 帶給IT 產業的啟示, 375 16.1 Android 美何在? 16.2 ...
第2章包装外观(Wrapper Façade):用于在类中封装函数的结构型模式 第3章 IPC SAP:用于高效、可移植和灵活的网络编程的C++包装 第4章 ACE轻量级OS并发机制的OO封装 第5章 C/C++线程专有存储(Thread-Specific ...
软件设计模式,结构型模式:Adapter Bridge Composite Decorator Façade FlyWeight Proxy
[GOF《设计模式》]门面模式没有一个一般化的类图描述,下面是一个示意性的对象图:外观模式为子系统中的接口定义了一个统一的更高层次的界面,以便于使用。当消费者按照目录采购时,则体现了一个外观模式。消费者...
ADE7854A/ADE7858A/ADE7868A/ADE7878A与 ADE7854/ADE7858/ADE7868/ADE7878系列产品之间的差异
FAÇADE PATTERN DECORATOR PATTERN FLYWEIGHT PATTERN TEMPLATE METHOD PATTERN MEDIATOR PATTERN CHAIN OF RESPONSIBILITY ... OBSERVER PATTERN STRATEGY PATTERN COMMAND PATTERN VISITOR PATTERN STATE PATTERN...
ACE提供了一组丰富的可复用C++包装外观(Wrapper Façade)和构架组件,可跨越多种平台完成通用的通信软件任务,其中包括:事件多路分离和事件处理器分派、信号处理、服务初始化、进程间通信、共享内存管理、消息...
5、Façade 外观、门面 6、Flyweight 享元模式 7、Proxy 代理模式 11个行为模式: 1、Chain of Responsibility 职责链 2、Command 命令 3、Interpreter 解释器 4、Iterator 迭代器 5、Mediator 中介者 6、...
基于ADE78xx/ADE7953的电能表校准 电能计量原理 ADE78xx和ADE7953校准基本公式 ADE78xx电表和ADE7953电表校准