动机(Motivate):
    在软件开发系统中，客户程序经常会与复杂系统的内部子系统之间产生耦合，而导致客户程序随着子系统的变化而变化。那么如何简化客户程序与子系统之间的交互接口？如何将复杂系统的内部子系统与客户程序之间的依赖解耦？
意图(Intent):
    为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
                                                                         --------《设计模式》GOF
结构图(Struct):

适用性：

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

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

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

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

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

//顾客类

    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;}}
}

看客户程序的调用：

//客户程序

    class Program{private const int _amount = 12000;static void Main(string[] args){Bank bank = new Bank();Credit credit = new Credit();Loan loan = new Loan();Customer customer = new Customer("Ann McKinsey");bool eligible = true;if (!bank.HasSufficientSavings(customer, _amount)){eligible = false;}else if (!credit.HasGoodCredit(customer)){eligible = false;}else if (!loan.HasNoBadLoans(customer)){eligible = false;}Console.WriteLine("\n" + customer.Name + " has been " + (eligible ? "Approved" : "Rejected"));Console.ReadLine();}}

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

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

    //银行子系统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; }}}

外观类Mortage的实现如下：

    /// <summary>/// 外观类/// </summary>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;}}

而此时客户程序的实现：

//客户程序类

    class Program{private const int _amount = 12000;static void Main(string[] args){//外观Mortgage mortgage = new Mortgage();Customer customer = new Customer("Ann McKinsey");bool eligable = mortgage.IsEligible(customer, _amount);Console.WriteLine("\n" + customer.Name + " has been " + (eligable ? "Approved" : "Rejected"));Console.ReadLine();        }}

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

.NET架构中的Facade模式

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

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

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

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

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

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

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

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

从图中可以看到，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 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;}}elsereturn false;}}

Facade模式的个要点：
    从客户程序的角度来看，Facade模式不仅简化了整个组件系统的接口，同时对于组件内部与外部客户程序来说，从某种程度上也达到了一种“解耦”的效果----内部子系统的任何变化不会影响到Facade接口的变化。

Facade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Facdae很多时候更是一种架构
设计模式。
    注意区分Facade模式、Adapter模式、Bridge模式与Decorator模式。Facade模式注重简化接口，Adapter模式注重转换接口，Bridge模式注重分离接口（抽象）与其实现，Decorator模式注重稳定接口的前提下为对象扩展功能。

转载于:https://www.cnblogs.com/1285026182YUAN/p/5162752.html

10.外观模式（Facade Pattern）相关推荐

  1. 如何让孩子爱上设计模式 ——11.外观模式(Facade Pattern)

    如何让孩子爱上设计模式 --11.外观模式(Facade Pattern) 标签: 设计模式初涉 场景引入 相信各位玩过LOL英雄联盟游戏的童鞋,对下面两个英雄都不会陌生吧:       分别是瑞雯和 ...

  2. 设计模式 -结构型模式_门面模式(外观模式) Facade Pattern 在开源软件中的应用

    文章目录 Pre 定义 案例 Demo V1.0 Boss直接管理 V2.0 引入外观类 PmManagerFacade 何时使用Facade Tomcat Mybatis Pre 我们先来回顾下门面 ...

  3. 使用C#实现适配器模式 (Adapter Pattern) 和外观模式 (Facade Pattern)

    本文的概念内容来自深入浅出设计模式一书 现实世界中的适配器(模式) 我带着一个国标插头的笔记本电脑, 来到欧洲, 想插入到欧洲标准的墙壁插座里面, 就需要用中间这个电源适配器. 面向对象的适配器 你有 ...

  4. 设计模式(八): 从“小弟”中来类比外观模式(Facade Pattern)

    在此先容我拿"小弟"这个词来扯一下淡.什么是小弟呢,所谓小弟就是可以帮你做一些琐碎的事情,在此我们就拿"小弟"来类比"外观模式".在上面一篇 ...

  5. php facade模,PHP 设计模式之外观模式 Facade

    简单描述 外观模式(Facade pattern),为子系统中的一组接口提供一个统一的高层接口,使得子系统更容易使用. 外观模式又称为门面模式,它是一种对象结构型模式,遵循迪米特法则,又称最少知道原则 ...

  6. .net 有哪些主流的设计模式_「设计模式自习室」门面模式 Facade Pattern

    前言 <设计模式自习室>系列,顾名思义,本系列文章带你温习常见的设计模式.主要内容有: 该模式的介绍,包括: 引子.意图(大白话解释) 类图.时序图(理论规范) 该模式的代码示例:熟悉该模 ...

  7. 【设计模式自习室】门面模式 Facade Pattern

    前言 <设计模式自习室>系列,顾名思义,本系列文章带你温习常见的设计模式.主要内容有: 该模式的介绍,包括: 引子.意图(大白话解释) 类图.时序图(理论规范) 该模式的代码示例:熟悉该模 ...

  8. 【白话设计模式二】外观模式(Facade)

    为什么80%的码农都做不了架构师?>>>    #0 系列目录# 白话设计模式 工厂模式 单例模式 [白话设计模式一]简单工厂模式(Simple Factory) [白话设计模式二] ...

  9. Web中的积累：外观模式 Facade

    摘要: 原创出处: http://www.cnblogs.com/Alandre/ 泥沙砖瓦浆木匠 希望转载,保留摘要,谢谢! 壹 前言 目测好久没写文章了,距离上一篇文章也有二十多天.我是怎么了?哈 ...

  10. 设计模式:外观模式(Facade)

    外观模式(Facade)也叫过程模式, 外观模式为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用. 外观模式通过定义一个一致的接口,用以屏蔽内部子系 ...

最新文章

  1. php 字符串数组转数组对象_php怎么将数组转成对象？
  2. XML配置文件的命名空间与Spring配置文件中的头
  3. android 网络图片查看器，Handler的用法
  4. jQuery的链式操作
  5. html 按下和松开事件,利用JQuery实现一个键盘按下与松开触发事件
  6. C语言实例第7期：实现投票统计功能
  7. 新浪股票数据接口获取
  8. 警惕：ERP系统不堪重负的几大预警信号
  9. c语言转换成delphi程序语言
  10. mysql怎么把两个表格的数据合并成一行_mysql中将多行数据合并成一行数据
  11. 甘肃SEO优化：关键词选择 是否“咨询”过关键词规划师以及seo优化技术大牛是怎么练成的
  12. JavaMail实现邮件的发送
  13. ARMv8 Linux内核head.S源码分析
  14. 使用CMAES算法预测PUF及XOR PUF的响应
  15. 什么是特征向量和特征值
  16. 电容的区别，关键在于介质
  17. 智能客服机器人的优势，促进客户服务自动化
  18. 说说我在家乡山东日照的面试经历以及对家乡互联网产业的一些认识吧
  19. 数据库的基本概念与组成
  20. 别名(Alias)-Yii 约定-深入理解YII2.0(2.2)

热门文章

  1. sql基础教程mysql_SQL基础教程（第2版）笔记整理
  2. ifstream java_C ifstream将读取一些值然后停止
  3. vim全局搜索并跳转
  4. leetcode算法题--把数字翻译成字符串
  5. ios android 录音格式,跨系统的录音格式兼容性问题: iOS Android
  6. python录制视频和声音_【Python记 #2】有声录屏
  7. fabric.js 不同类型 不同控件_耐温灌封胶都哪几个类型？不同类型的灌封胶有哪些不同之处？...
  8. Java-Shiro（三）：Shiro与Spring MVC集成
  9. Serverless在游戏、电商行业的一个运用场景示例
  10. 基于虚拟账号的邮件系统