外观模式

这几天一直在研究各种各样的设计模式，在学习适配器模式、桥接模式和外观模式模式的时候，发现他们之间存在着一定的关系，实际上模式不适单一存在的，在我们的现实编程生活中往往是几种模式结合使用的。 　　1．适配器模式与桥接模式的区别和联系 　　适配器模式和桥接模式都是间接引用对象，因此可以使系统更灵活，在实现上都涉及从自身以外的一个接口向被引用的对象发出请求。 　 　两种模式的区别在于使用场合不同，适配器模式主要解决两个已有接口间的匹配问题，这种情况下被适配的接口的实现往往是一个黑匣子。我们不想，也不能修改 这个接口及其实现。同时也不可能控制其演化，只要相关的对象能与系统定义的接口协同工作即可。适配器模式经常用在与第三方产品的功能集成上，采用该模式适 应新类型的增加的方式是开发针对这个类型的适配器，如下所示。 　　桥接模式则不同，参与桥接的接口是稳定的，用户可以扩展和修改桥接中的类，但是不能改变接口。桥接模式通过接口继承或者继承实现功能扩展，如图所示。 　　按照GOF的说法，桥接模式和适配器模式用于设计的不同阶段，桥接模式用于设计的前期，即在设计类时将类规划为逻辑和实现两个大类，使它们可以分别进行演化；而适配器模式用于设计完成之后，当发现设计完成的类无法协同工作时，可以采用适配器模式。 然而，很多情况下在设计初期就要考虑适配器模式的使用，如涉及大量第三方应用接口的情况。 　　2

北风设计模式课程---外观模式、代理模式和中介者模式的区别 一、总结 一句话总结： 1、外观模式（Facade Pattern）：外观类隐藏子系统的复杂性 2、代理模式（Proxy Pattern）：用一个代理类代表另一个类的功能 3、中介者模式（Mediator Pattern）：用一个中介对象来封装一系列的对象交互：比如男人类和女人类之间的交互给媒婆 二、外观模式、代理模式和中介者模式的区别 转自或参考：外观模式、代理模式和中介者模式的区别 https://blog.csdn.net/cjxunooo/article/details/84985679 外观模式（Facade Pattern） 定义一个外观类，外观类隐藏系统的复杂性，为客户端提供简化的方法和对现有系统类方法的委托调用。 例如：二手房交易的中介，属于外观模式。买房者通过中介可以简单地买到二手房，中介自己把联系房东看房砍价、过户、交税这些复杂的事情都搞定了。 代理模式（Proxy Pattern） 用一个代理类代表另一个类的功能，但是不改变被代理类的功能。目的是控制对被代理类的访问。 中介者模式（Mediator Pattern） 用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。将各对象之间的网状结构分离为星型结构。 例如：MVC 框架

外观模式简介 要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供了一个高层次的接口，使得子系统更易于使用。 为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。 降低访问复杂系统的内部子系统时的复杂度，简化客户端与之的接口。 C# 外观模式Demo using System ; namespace FacadePattern { class Program { static void Main ( string [ ] args ) { FruitMarker fruitMarker = new FruitMarker ( ) ; fruitMarker . BuyApple ( ) ; fruitMarker . BuyOrange ( ) ; fruitMarker . BuyPeach ( ) ; fruitMarker . BuyAllFruit ( ) ; } } public abstract class Fruit { public abstract void BuyFruit ( ) ; } public class Orange : Fruit { public override void BuyFruit ( ) { Console . WriteLine ( "买了一个橘子" ) ;

什么是外观模式 外观（Facade）模式是属于结构型模式，通过提供外观的包装隐藏系统的复杂性。 火箭发射系统很复杂，但真正使用它的人，可能就需要一个按钮，让它发射就好。那么发射按钮就隐藏了启动程序及发射系统的复杂性。 我们用的各种第三方库，大多也是通过给用户提供 API 来简化和隐藏内部的复杂实现。 实例 现在好多商店都在用微信或者支付宝扫码收款，如果放两个二维码经常会有顾客扫错，那么就可以应用外观模式，将不同的二维码整合成一个，通过系统内部区分。除此之外，我们还可以做额外的扩展。 class PayCode { constructor ( ) { this . record = [ ] } pay ( args ) { if ( args . wechat ) { this . record . push ( { type : 'wechat' , amount : args . amount } ) console . log ( `微信到账 ${ args . amount } 元` ) } if ( args . alipay ) { this . record . push ( { type : 'alipay' , amount : args . amount } ) console . log ( `支付宝到账 ${ args . amount } 元` ) } }

概念解读 外观模式(facade): 为子系统中的一组接口提供一个一致的表现,使得子系统更容易使用而不需要关注内部复杂而繁琐的细节.比如下图就是一个很好形象的说明外观模式的设计思路 作用 对接口和调用者进行了一定的解耦 创造经典的三层结构MVC 在开发阶段减少不同子系统之间的依赖和耦合,方便各个子系统的迭代和扩展 为大型复杂系统提供一个清晰的接口 function on(type, fn){ // 对于支持dom2级事件处理程序 if(document.addEventListener){ dom.addEventListener(type,fn,false); }else if(dom.attachEvent){ // 对于IE9一下的ie浏览器 dom.attachEvent('on'+type,fn); }else { dom['on'+ type] = fn; } } 注意事项 当外观模式被开发者连续调用时会造成一定的性能损耗,这是由于每次调用都会进行可用性检测 实际案例 我们可以使用外观模式来设计兼容不同浏览器的事件绑定的方法以及其他需要统一实现接口的方法或者抽象类. 意图： 为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。 主要解决： 降低访问复杂系统的内部子系统时的复杂度，简化客户端与之的接口。 何时使用： 1

外观模式 //外观模式 public class Facade { private SubSystem1 subSystem1 = new SubSystem1(); private SubSystem2 subSystem2 = new SubSystem2(); private SubSystem3 subSystem3 = new SubSystem3(); public void method(){ subSystem1.methhod1(); subSystem2.methhod2(); subSystem3.methhod3(); } } //子系统一 public class SubSystem1 { public void methhod1(){ System.out.println("调用子系统一"); } } //子系统二 public class SubSystem2 { public void methhod2(){ System.out.println("调用子系统二"); } } //子系统三 public class SubSystem3 { public void methhod3(){ System.out.println("调用子系统三"); } } //测试一下！ public class test { public static void

场景问题 示例 ：组装电脑 通常一般来说有俩种方案，一种是自己组装，第二种是找到装机公司，告诉他们具体要求，然后等着拿电脑就好了，如果把上面的过程看作是一个系统，那么第二种方案的装机公司就相当于我们 外观模式 （facade） 不同场景下的解决方案 以代码生成工具为例，假使我们的代码生成工具生成的模块都具有三层架构（表现层，逻辑层，数据层） 我们要想实现这个简单的工具，需要描述配置的数据Model,获取配置信息的实现，逻辑层的实现，表现层的实现，即使我们这里不采用代码说明，我们也可以想象得出，客户端为了使用生成代码的功能，需要和代码子系统的多隔模块进行交互，这与客户端来说，是一个麻烦，系统的编程应该尽量解耦 解决方案 由此我们可以使用一个合理的解决方案那就是外观模式 是什么 为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易利用 为什么 客户端想要操作简单一点，那就需要根据客户端的需要来客户端定义一个简单的接口，然后如客户端调用这个接口，当然这里的接口就是客户端与访问系统之间的通道（并不是特指java里的接口，在外观模式中，通常是类） 示例代码 定义模块A * @author tan * */ public interface AModelApi { /** * A 模块暴露的方法 */ void testA(); }

一 引言 外观模式（Facade）其实在开发过程中使用评率十分频繁，或间接或直接使用，尤其是在当前各种第三方SDK 中，相当大的概率使用了外观模式，通过一个外观类使用的整个SDK的接口只有一个统一的高层接口，降低了用户对接成本，也对用户屏蔽了具体实现细节。 二 定义 外观模式： 外部与一个子系统的通信必须通过一个统一的外观对象进行，为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。外观模式又称为门面模式。 外观模式核心思想在于“统一的对象”，即是提供一个访问子系统的接口，除了这个接口不允许有任何访问子系统的行为发生（子系统是个概念，是所有类的简称，它可能代表一个类，也可能代表几十个对象的集合），外观对象是外界访问子系统内部的唯一通道，不管子系统内部是多么杂乱无章，所以外观模式的核心参与者有：外观对象和各种子系统角色。 关键词：增加Facade层。 通过外观的包装，使应用程序只能看到外观对象，而不会看到具体的细节对象，这样无疑会降低应用程序的复杂度，并且提高了程序的可维护性。 三 模式分析 根据“单一职责原则”，在软件中将一个系统划分为若干个子系统有利于降低整个系统的复杂性，一个常见的设计目标是使子系统间的通信和相互依赖关系达到最小，而达到该目标的途径之一就是引入一个外观对象，它为子系统的访问提供了一个简单而单一的入口。

外观模式的定义与特点 外观（Facade）模式的定义：是一种通过为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口，外部应用程序不用关心内部子系统的具体的细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性。 外观（Facade）模式是“迪米特法则”的典型应用，它有以下主要优点。 降低了子系统与客户端之间的耦合度，使得子系统的变化不会影响调用它的客户类。 对客户屏蔽了子系统组件，减少了客户处理的对象数目，并使得子系统使用起来更加容易。 降低了大型软件系统中的编译依赖性，简化了系统在不同平台之间的移植过程，因为编译一个子系统不会影响其他的子系统，也不会影响外观对象。 外观（Facade）模式的主要缺点如下。 不能很好地限制客户使用子系统类。 增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。 外观模式的结构与实现 外观（Facade）模式的结构比较简单，主要是定义了一个高层接口。它包含了对各个子系统的引用，客户端可以通过它访问各个子系统的功能。现在来分析其基本结构和实现方法。 1. 模式的结构 外观（Facade）模式包含以下主要角色。 外观（Facade）角色：为多个子系统对外提供一个共同的接口。 子系统（Sub System）角色：实现系统的部分功能，客户可以通过外观角色访问它。 客户（Client）角色

1) 意图： 为子系统中的一组接口提供一个一致的界面， Facade 模式定义了一个高层接口，这个接口使得子系统更加容易使用 2) 结构： 3) 适用性： 为一个复杂子系统提供一个简单接口时 为了提高子系统的独立型和可移植性 当需要构建一个层次结构的子系统时，使用 Facade 模式定义子系统每层的入口点 4) 举例： 1 #include <iostream> 2 #include <list> 3 class SubSystem1 4 { 5 public: 6 SubSystem1() {} 7 virtual ~SubSystem1() {} 8 virtual void Operation1() 9 { 10 std::cout << "Operation1" << std::endl; 11 } 12 }; 13 class SubSystem2 14 { 15 public: 16 SubSystem2() {} 17 virtual ~SubSystem2() {} 18 virtual void Operation2() 19 { 20 std::cout << "Operation2" << std::endl; 21 } 22 }; 23 class SubSystem3 24 { 25 public: 26 SubSystem3() {} 27