外观模式

外观模式 外观模式 ，为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。 该模式起名为外观模式就很能体现出他的特点，一个子系统里得内容太过复杂，以至于另一个模块调用的时候不方便，所以创造一个“外观类”，用这个类包含整个子系统里的其他类，然后另一个模块调用的时候统一使用该外观类即可。 注：该模式没有继承关系，是组合关系。 优点： 减少了系统的相互依赖 提高了灵活性。不管系统内部如何变化，只要不影响到外观对象，任你自由活动 提高了安全性。想让你访问子系统的哪些业务就开通哪些逻辑，不在外观上开通的方法，你就访问不到 缺点： 不符合开闭原则 使用场景： 回顾项目用的MVP模式或MVC模式，可以考虑在数据访问层和业务逻辑层、业务逻辑层和表示层的层与层之间简历外观Facade，降低耦合。 来源： https://www.cnblogs.com/LampsAsarum/p/12191342.html

第13章：外观模式 13.1 影院管理项目 组建一个家庭影院： DVD 播放器、投影仪、自动屏幕、环绕立体声、爆米花机,要求完成使用家庭影院的功能，其过程为： 直接用遥控器：统筹各设备开关 开爆米花机 放下屏幕 开投影仪 开音响 开 DVD，选 dvd 去拿爆米花 调暗灯光 播放 观影结束后，关闭各种设备 二、传统方式解决影院管理 ​ 三、传统方式解决影院管理问题分析 在 ClientTest 的 main 方法中，创建各个子系统的对象，并直接去调用子系统(对象)相关方法，会造成调用过程混乱，没有清晰的过程； 不利于在 ClientTest 中，去维护对子系统的操作； 解决思路： 定义一个高层接口 ，给 子系统中的一组接口提供一个一致的界面 (比如在高层接口提供四个方法 ready, play, pause, end )，用来访问子系统中的一群接口 - 也就是说 就是通过定义一个一致的接口(界面类)，用以屏蔽内部子系统的细节，使得调用端只需跟这个接口发生调用，而无需关心这个子系统的内部细节 => 外观模式** 四、外观模式基本介绍 外观模式（Facade），也叫“过程模式：外观模式为子系统中的一组接口 提供一个一致的界面 ，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用； 外观模式通过定义一个一致的接口，用 以==屏蔽内部子系统的细节== ，使得

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 模式分析： 外观模式又称为门面模式，提供一个统一的接口，用来访问子系统中的一群接口，外观定义了一个高层的接口，让子系统更容易使用。 门面(Facade)角色 ： 客户端可以调用这个角色的方法。此角色知晓相关的（一个或者多个）子系统的功能和责任。在正常情况下，本角色会将所有从客户端发来的请求委派到相应的子系统去。 子系统(SubSystem)角色 ： 可以同时有一个或者多个子系统。每个子系统都不是一个单独的类，而是一个类的集合（如上面的子系统就是由ModuleA、ModuleB、ModuleC三个类组合而成）。每个子系统都可以被客户端直接调用，或者被门面角色调用。子系统并不知道门面的存在，对于子系统而言，门面仅仅是另外一个客户端而已。 一个系统可以有几个门面类 　　在门面模式中，通常只需要一个门面类，并且此门面类只有一个实例，换言之它是一个单例类。当然这并不意味着在整个系统里只有一个门面类，而仅仅是说对每一个子系统只有一个门面类。或者说，如果一个系统有好几个子系统的话，每一个子系统都有一个门面类，整个系统可以有数个门面类。 模式优点： 松散耦合： 门面模式松散了客户端与子系统的耦合关系，让子系统内部的模块能更容易扩展和维护。 简单易用： 门面模式让子系统更加易用，客户端不再需要了解子系统内部的实现

外观 是一种结构型设计模式， 能为复杂系统、 程序库或框架提供一个简单 （但有限） 的接口。 尽管外观模式降低了程序的整体复杂度， 但它同时也有助于将不需要的依赖移动到同一个位置。 在 Java 中使用模式 复杂度：⭐ 流行度：⭐⭐ 使用示例： 使用 Java 开发的程序中经常会使用外观模式。 它在与复杂程序库和 API 协作时特别有用。 下面是一些核心 Java 程序库中的外观示例： javax.faces.context.FacesContext 在底层使用了 Life­Cycle 、 View­Handler 和 Navigation­Handler 这几个类， 但绝大多数客户端不知道。 javax.faces.context.ExternalContext 在内部使用了 Servlet­Context 、 Http­Session 、 Http­Servlet­Request 、 Http­Servlet­Response 和其他一些类。 识别方式： 外观可以通过使用简单接口， 但将绝大部分工作委派给其他类的类来识别。 通常情况下， 外观管理着其所使用的对象的完整生命周期。 复杂视频转换库的简单接口 在本例中， 外观简化了复杂视频转换框架所进行的沟通工作。 外观提供了仅包含一个方法的类， 可用于处理对框架中所需类的配置与以正确格式获取结果的复杂工作。 some

外观模式的目的在于如何简化接口，可以将多个类的复杂的一切隐藏在背后，值显露一个干净美观的外观。 所谓的外观模式就是提供一个统一的接口，用来访问子系统中的一群接口。 外观模式定义了一个高级接口，让子系统更容易使用， 外观模式的UML图 外观模式的代码实现 创建3个子部件 /** * 子系统角色：空调 */ public class Air { public void open ( ) { System . out . println ( "开空调" ) ; } public void shutDown ( ) { System . out . println ( "关空调" ) ; } } /** * 子系统角色：灯 */ public class Light { public void open ( ) { System . out . println ( "开灯" ) ; } public void shutDown ( ) { System . out . println ( "关灯" ) ; } } /** * 子系统角色：电视 */ public class Tv { public void open ( ) { System . out . println ( "开电视" ) ; } public void shutDown ( ) { System . out .

建造者模式概述 建造者模式是较为复杂的创建型模式，它将客户端与包含多个组成部分（或部件）的复杂对象的创建过程分离，客户端无须知道复杂对象的内部组成部分与装配方式，只需要知道所需建造者的类型即可。它关注如何一步一步创建一个的复杂对象，不同的具体建造者定义了不同的创建过程，且具体建造者相互独立，增加新的建造者非常方便，无须修改已有代码，系统具有较好的扩展性。 建造者模式结构 ● Builder（抽象建造者）：它为创建一个产品 Product 对象的各个部件指定抽象接口，在该接口中一般声明两类方法，一类方法是 buildPartX()，它们用于创建复杂对象的各个部件；另一类方法是 getResult()，它们用于返回复杂对象。Builder既可以是抽象类，也可以是接口。 ● ConcreteBuilder（具体建造者）：它实现了 Builder 接口，实现各个部件的具体构造和装配方法，定义并明确它所创建的复杂对象，也可以提供一个方法返回创建好的复杂产品对象。 ● Product（产品角色）：它是被构建的复杂对象，包含多个组成部件，具体建造者创建该产品的内部表示并定义它的装配过程。 ● Director（指挥者）：指挥者又称为导演类，它负责安排复杂对象的建造次序，指挥者与抽象建造者之间存在关联关系，可以在其 construct() 建造方法中调用建造者对象的部件构造与装配方法

外观模式思维导图 设计模式-外观模式 1、定义 定义一个高层接口，使子系统更易使用，提供一致界面。（简化用户与子系统的交互。） 2、分类 分类：结构型模式。 3、优点&缺点 优点： 使客户和子系统的类无耦合，子系统使用更方便； 只提供更简洁界面，不影响用户直接使用子系统的类； 子系统中任何类的方法的改变，不影响外观类。 缺点： 不满足开闭原则；（在不引入抽象外观类时，增加新的子系统可能会改变外观类代码。） 不能很好限制用户使用子系统。 遵循迪米特法则：一个类对自己依赖的类知道的越少越好。即，对于被依赖的类，无论逻辑多么复杂，尽量将逻辑封装在类的内部。 4、适用场景 对于复杂子系统，需为用户提供简单交互操作； 不希望客户与子系统的类耦合，提高子系统独立性和可移植性； 当整个系统需要构建一个层次结构的子系统，不希望子系统相互直接交互。 5、UML类图 角色： 子系统 Subsystem：若干类的集合，这些类的实例协同为用户提供所需功能。 外观 Facade：包含子系统全部或部分类的实例引用。 6、代码实现 //step1. 子系统 Subsystem：若干类的集合，这些类的实例协同为用户提供所需功能 class ClassA { public void methodA ( ) { System . out . println ( "method A" ) ; } } class

一、定义 代理模式（Proxy）：为其他对象提供一种代理以控制对这个对象的访问。 适配器模式（Adapter）：将一个类的接口转换成客户希望的另外一个接口，使得原本接口不兼容而不能一起工作的那些类可以一起工作。 外观模式（Facade）：为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。 二、理解 代理模式和适配器模式应该说很相像，但是他们的区别也很明显，代理模式和被代理者的接口是同一个，只是使用中客户访问不到被代理者，所以利用代理间接的访问，而适配器模式，是因为接口不同，为了让用户使用到统一的接口，把原先的对象通过适配器让用户统一的使用，大多数运用在代码维护的后期，或者借用第三方库的情况下 ，而外观模式，是大家经常无意中使用的，就是把错综复杂的子系统关系封装起来，然后提供一个简单的接口给客户使用，就类似于一个转接口，可以想象成一个漏斗，中间细的那一段，越细耦合度越低，外观模式就是为了降低耦合度。 三、类图 代理模式 适配器模式 外观模式 四、Code 代理模式，代理者保存一个被代理的一个对象；适配器模式，保存了一个被适配的对象；而外观模式，就保存了各个子系统对象，然后根据实际逻辑组合。 一、定义 代理模式（Proxy）：为其他对象提供一种代理以控制对这个对象的访问。 适配器模式（Adapter）

什么是外观模式？ 外观模式（Facade），为子系统中的一组接口提供一个一致的界面，定义一个高层接口，这个接口使得这一子系统更加easy使用。 简单点说：外观模式是一种使用频率很高的结构型设计模式。它通过引入一个外观角色来简化client与子系统之间的交互。为复杂的子系统调用提供一个统一的入口，减少子系统与client的耦合度，且client调用很方便。 概述: 在真实的应用系统中。一个子系统可能由非常多类组成。子系统的客户为了它们的须要。须要和子系统中的一些类进行交互。客户和子系统的类进行直接的交互会导致client对象和子系统之间高度耦合。不论什么的类似于对子系统中类的接口的改动。会对依赖于它的全部的客户类造成影响。 从上面外观模式的定义我们看以看到外观模式能非常好的解决上述问题， 为子系统提供了一个更高层次、更简单的接口，从而减少了子系统的复杂度和依赖。 这使得子系统更易于使用和管理。 外观是一个能为子系统和客户提供简单接口的类。当正确的应用外观。客户不再直接和子系统中的类交互，而是与外观交互。外观承担与子系统中类交互的责任。 实际上。外观是子系统与客户的接口。这样外观模式减少了子系统和客户的耦合度。 实例： 以下用一个简单的样例来说明外观模式： 结构图： 子系统类一般是一些业务类。实现了一些详细的、独立的业务功能，其典型代码例如以下： class One{ public

定义： 提供了一个统一的接口，用于访问子系统一群功能的相关接口。就是将一群子系统，或者对象，或者接口等继续统筹，分类，组装成统一的接口，解耦内部和外部，同时降低复杂度。通俗的说，就是在一群接口外面再包一层。 图示： 案例分析： 假如我们要进行炒菜，这个过程中，对象有煤气罐（GasCylinder），炉灶（KitchenRange），食物（food），佐料（condiment）。 那么操作过程为： 1-> 打开煤气（GasCylinder） 2-> 打开炉灶(KitchenRange) 3-> 下油（condiment） 4-> 下食物（food） 5-> 下盐（condiment） 6-> 关闭炉灶（KitchenRange） 7->关闭煤气（GasCylinder） 一个人要完成炒菜过程，需要协调多个对象，发生什么变更，可维护性变得很差，例如将煤气变成天然气，这时变动将变得超级复杂，从外部到内部需要调整，过于复杂，耦合性过于高。 经过分析，一个炒菜过程可以分为三个步骤，第一起火，第二炒菜，第三关火，那么可以设计一个对象，来协调封装这些复杂，炒菜的人只需要关系他要执行的三个步骤即可。 代码实例如下： 对象类： public class Food { private static Food food = null; private Food() { }; public static