facade

概述 　　结构型模式共七种： 适配器模式（Adapter）　　　　　　　　 外观模式（Facade） 桥接模式（Bridge） 装饰器模式（Decorator） 代理模式（Proxy） 享元模式（Flyweight） 组合模式（Composite） 　　其中又分为 　　接口适配：适配器、外观、桥接模式 　　行为扩展：装饰 　　性能与对象访问：代理、享元模式 　　抽象集合：组合模式 一、适配器模式 　　定义：将一个类的接口转换成客户希望的另外一个接口，Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 　　角色：适配器（Adapter）、被适配类、对象（Adaptee） 　　理解：客户需要Target，现实只有Adaptee，可以用一个实现Target协议的适配器通过类继承或者对象组合类获得被Adaptee。 　　类图： 　　 　　例子代码： // 原有的接口，不符合客户要求 interface IOrigin{ public void deal(); } // 定义一个符合客户要求的新接口 interface ITarget{ public void newDeal( int type); } class Target implements ITarget{ private IOrigin origin; public void newDeal( int

前言 结构型模式：这些设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象获得新功能的方式。 适配器模式（Adapter Pattern） 桥接模式（Bridge Pattern） 过滤器模式（Filter、Criteria Pattern） 组合模式（Composite Pattern） 装饰器模式（Decorator Pattern） 外观模式（Facade Pattern） 享元模式（Flyweight Pattern） 代理模式（Proxy Pattern） 1. 适配器模式 将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以在一起工作。 我们用图来形象的解释这一概念： 这里的重点在于，老接口有特殊功能，我们不忍舍弃，比如只有欧洲的插头（老接口）能从插座里获得电，没有电我们过不下去。这个功能我们无法舍弃 为了继续享受这个特殊功能，我们使用适配器模式，让我们手中的美国的插头（新接口），拥有老接口的能力。 1.1 Demo 例如一个美国人说英语，一个中国人说中文，为了跟美国人做生意，说英文这个功能我们无法舍弃，但是我们是中国人，天生不会说英文。于是两者想要交流，就需要一个适配器，来充当沟通两者的工作。现在，我们希望让一个能说中国话的个体（实现说中文的接口的类），开口说英文。 1.1.1 角色 目标接口

　　一、引言 　　在软件开发过程中，有些对象有时候会由于网络或其他的障碍，以至于不能够或者不能直接访问到这些对象，如果直接访问对象给系统带来不必要的复杂性。这时候可以在客户端和目标对象之间增加一层中间层，让代理对象代替目标对象，然后客户端只需要访问代理对象，由代理对象去帮我们去请求目标对象并返回结果给客户端，这样的一个解决思路就是今天要介绍的代理模式。 　　二、代理模式的详细介绍 　　代理模式按照使用目的可以分为以下几种： 　　1）远程（Remote）代理：为一个位于不同的地址空间的对象提供一个局域代表对象。这个不同的地址空间可以是本电脑中，也可以在另一台电脑中。最典型的例子就是——客户端调用Web服务或WCF服务。 　　2）虚拟（Virtual）代理：根据需要创建一个资源消耗较大的对象，使得对象只在需要时才会被真正创建。 　　3）Copy-on-Write代理：虚拟代理的一种，把复制（或者叫克隆）拖延到只有在客户端需要时，才真正采取行动。 　　4）保护（Protect or Access）代理：控制一个对象的访问，可以给不同的用户提供不同级别的使用权限。 　　5）防火墙（Firewall）代理：保护目标不让恶意用户接近。 　　6）智能引用（Smart Reference）代理：当一个对象被引用时，提供一些额外的操作，比如将对此对象调用的次数记录下来等。 　　7）Cache代理

定义： 外观模式（Facade）： 又叫门面模式，为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。 代码实例： 假设实现一个功能需要用到子系统中的四个方法。 /* * * Class SubSystemOne */ class SubSystemOne { public function methodOne() { return '子系统方法一' . '<br>' ; } } /* * * Class SubSystemTwo */ class SubSystemTwo { public function methodTwo() { return '子系统方法二' . '<br>' ; } } /* * * Class SubSystemThree */ class SubSystemThree { public function methodThree() { return '子系统方法三' . '<br>' ; } } /* * * Class SubSystemFour */ class SubSystemFour { public function methodFour() { return '子系统方法四' . '<br>' ; } } 如果不使用外观模式，客户端代码应该为： $subSystemOne = new

外观模式是一种使用频率非常高，但理解较为简单的设计模式，通过引入一个外观角色来简化客户端与子系统之间的操作，为复杂的子系统调用提供一个统一的入口，使子系统与客户端的耦合度降低，且客户端调用非常方便。 模式动机 在大多数情况下，一个网站都会提供一个网站首页。网站首页一般作为整个网站的入口，提供了通往各个子栏目的超链接，用户通过该首页即可进入子栏目获取所需信息。对于用户而言只需记住网站首页网站 URL，而无须记住每个子栏目的网址。网站首页作为用户访问子栏目的入口，是网站的外观角色。用户通过它可以方便地访问子栏目，当然也可以绕过它直接访问子栏目。 如果没有外观角色，即没有为网站提供一个首页，每个用户需要记住所有子栏目的 URL，不仅会让系统耦合度增加，用户与系统的交互也会异常复杂。 模式定义 外部与一个子系统的通信必须通过一个统一的外观对象进行，为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加易于使用。 模式结构 外观模式没有一个一般化的类图描述，这里以类图作为外观模式的描述形式之一。 Facade（外观角色） 在客户端可以调用这个角色的方法，在外观角色中可以知道相关子系统的功能和责任；在正常情况下，它将所有从客户端发来的请求委派到相应子系统，传递给相应的子系统对象处理。 SubSystem（子系统角色）

目录 前言 项目版本 项目说明 集成Dubbo 2.6.x 新项目模块 老项目模块 集成Dubbo 2.7.x 新项目模块 老项目模块 参考资料 系列文章 前言 SpringCloud系列开篇文章就说到了，公司新项目将入坑SpringCloud全家桶，但原先线上老项目是采用Spring+Dubbo技术栈的，新项目中的部分业务还是和老项目有点关联的，重写这一部分业务逻辑也是需要点时间，本来想通过http请求进行业务交互的，总感觉不够优雅，原先也了解过SpringCloud Alibaba，趁着这个机会捣腾捣腾。 项目版本 spring-boot-version： 2.2.5.RELEASE spring-cloud.version： Hoxton.SR3 dubbo版本会分成2.6.x系列和2.7.x系列二个版本进行说明 dubbo2.6.x <dependency> <groupId>com.alibaba.boot</groupId> <artifactId>dubbo-spring-boot-starter</artifactId> <version>0.2.1.RELEASE</version> </dependency> <dependency> <groupId>com.alibaba</groupId> <artifactId>dubbo</artifactId>

外观模式是一种使用频率非常高，但理解较为简单的设计模式，通过引入一个外观角色来简化客户端与子系统之间的操作，为复杂的子系统调用提供一个统一的入口，使子系统与客户端的耦合度降低，且客户端调用非常方便。 模式动机 在大多数情况下，一个网站都会提供一个网站首页。网站首页一般作为整个网站的入口，提供了通往各个子栏目的超链接，用户通过该首页即可进入子栏目获取所需信息。对于用户而言只需记住网站首页网站 URL，而无须记住每个子栏目的网址。网站首页作为用户访问子栏目的入口，是网站的外观角色。用户通过它可以方便地访问子栏目，当然也可以绕过它直接访问子栏目。 如果没有外观角色，即没有为网站提供一个首页，每个用户需要记住所有子栏目的 URL，不仅会让系统耦合度增加，用户与系统的交互也会异常复杂。 模式定义 外部与一个子系统的通信必须通过一个统一的外观对象进行，为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加易于使用。 模式结构 外观模式没有一个一般化的类图描述，这里以类图作为外观模式的描述形式之一。 Facade（外观角色） 在客户端可以调用这个角色的方法，在外观角色中可以知道相关子系统的功能和责任；在正常情况下，它将所有从客户端发来的请求委派到相应子系统，传递给相应的子系统对象处理。 SubSystem（子系统角色）

目录 ☞ 23 种设计模式——创建型设计模式（5种） ☞ 23 种设计模式——结构型设计模式（7种） ☞ 23 种设计模式——行为型设计模式（11种） 3. 结构型设计模式 结构型模式描述如何将类或对象按某种布局组成更大的结构。 它分为类结构型模式和对象结构型模式，前者采用继承机制来组织接口和类，后者采用组合或聚合组合对象。 由于组合关系或聚合关系比较继承关系耦合度低，满足“合成复合原则”，所以对象结构型模式比类结构型模式具有更大的灵活性。 结构型模式分为以下 7 种： 1） 代理（Proxy）模式 ：为某对象提供一种代理以控制对象的访问。即客户端通过代理简介地访问该对象，从而限制、增强或修改该对象的一些特征。 2） 适配器（Adapter）模式 ：将一个类的接口转换成希望的另一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。 3） 桥接（Bridge）模式 ：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现的，从而降低了抽象和实现这两个可变维度的耦合度。 4） 装饰（Decorator）模式 ：动态地给对象增加一些职责，即增加其额外的功能。 5） 外观（Facade）模式 ：为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。 6） 享元（Flyweight）模式 ：运用共享技术来有效地支持大量细粒度对象的复用。 3.1 代理

目录 ☞ 23 种设计模式——创建型设计模式（5种） ☞ 23 种设计模式——结构型设计模式（7种） ☞ 23 种设计模式——行为型设计模式（11种） 3. 结构型设计模式 结构型模式描述如何将类或对象按某种布局组成更大的结构。 它分为类结构型模式和对象结构型模式，前者采用继承机制来组织接口和类，后者采用组合或聚合组合对象。 由于组合关系或聚合关系比较继承关系耦合度低，满足“合成复合原则”，所以对象结构型模式比类结构型模式具有更大的灵活性。 结构型模式分为以下 7 种： 1） 代理（Proxy）模式 ：为某对象提供一种代理以控制对象的访问。即客户端通过代理简介地访问该对象，从而限制、增强或修改该对象的一些特征。 2） 适配器（Adapter）模式 ：将一个类的接口转换成希望的另一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。 3） 桥接（Bridge）模式 ：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现的，从而降低了抽象和实现这两个可变维度的耦合度。 4） 装饰（Decorator）模式 ：动态地给对象增加一些职责，即增加其额外的功能。 5） 外观（Facade）模式 ：为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。 6） 享元（Flyweight）模式 ：运用共享技术来有效地支持大量细粒度对象的复用。 3.1 代理

在 IntelliJ IDEA 中，没有类似于 Eclipse 工作空间（Workspace）的概念，而是提出了 Project 和 Module 这两个概念。接下来，就让咱们一起看看 IntelliJ IDEA 官方是如何描述两者的吧！ 对于 Project，IntelliJ IDEA 官方是这样介绍的： A project is a top-level organizational unit for your development work in IntelliJ IDEA. In its finished form, a project may represent a complete software solution. A project is a collection of: Your work results: source code, build scripts, configuration files, documentation, artifacts, etc. SDKs and libraries that you use to develop, compile, run and test your code. Project settings that represent your working preferences in the context of