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

概述

在软件开发系统中，客户程序经常会与复杂系统的内部子系统之间产生耦合，而导致客户程序随着子系统的变化而变化。那么如何简化客户程序与子系统之间的交互接口？如何将复杂系统的内部子系统与客户程序之间的依赖解耦？这就是要说的 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(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();
    }
}

可以看到引入

.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  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]

效果及实现要点

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 外观模式 ( 结构型模式 ) 》