设计模式学习笔记--外观模式(详细笔记)

文章目录

• • 1. 概述
  • 2. 使用实例

1. 概述

使用背景：

菜鸟教程

降低访问复杂系统的内部子系统时的复杂度，简化客户端之间的接口。

定义：

《大话设计模式》

外观模式(Facade)，为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

菜鸟教程

外观模式（Facade Pattern）隐藏系统的复杂性，并向客户端提供了一个客户端可以访问系统的接口。这种类型的设计模式属于结构型模式，它向现有的系统添加一个接口，来隐藏系统的复杂性。

《图说设计模式》

外观模式(Facade Pattern)：外部与一个子系统的通信必须通过一个统一的外观对象进行，为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。外观模式又称为门面模式，它是一种对象结构型模式。

**类型：**结构型

结构：

《大话设计模式》

《深入设计模式》

适用场景：

《大话设计模式》

这要分三个阶段来说：

• 首先，在设计初期阶段，应该要有意识的将不同的两个层分离，比如经典的三层架构，就需要考虑在数据访问层和业务逻辑层、业务逻辑层和表示层的层与层之间建立外观Facade，这样可以为复杂的子系统提供一个简单的接口，使得耦合大大降低。
• 其次，在开发阶段，子系统往往因为不断的重构演化而变得越来越复杂，大多数的模式使用时也都会产生很多很小的类，这本是好事，但也给外部调用它们的用户程序带来了使用上的困难，增加外观 Facade可以提供一个简单的接口，减少它们之间的依赖。
• 第三，在维护一个遗留的大型系统时，可能这个系统已经非常难以维护和扩展了，但因为它包含非常重要的功能，新的需求开发必须要依赖于它。此时用外观模式Facade也是非常合适的。你可以为新系统开发一个外观 Facade类，来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口，让新系统与Facade对象交互，Facade与遗留代码交互所有复杂的工作。

菜鸟教程

• 为复杂的模块或子系统提供外界访问的模块。

• 子系统相对独立。

• 预防低水平人员带来的风险。

《深入设计模式》

• 如果你需要一个指向复杂子系统的直接接口， 且该接口的功能有限， 则可以使用外观模式。

子系统通常会随着时间的推进变得越来越复杂。 即便是应用了设计模式， 通常你也会创建更多的类。 尽管在多种情形中子系统可能是更灵活或易于复用的， 但其所需的配置和样板代码数量将会增长得更快。 为了解决这个问题， 外观将会提供指向子系统中最常用功能的快捷方式， 能够满足客户端的大部分需求。

• 如果需要将子系统组织为多层结构， 可以使用外观。

创建外观来定义子系统中各层次的入口。 你可以要求子系统仅使用外观来进行交互， 以减少子系统之间的耦合。

实现方式：

1. 考虑能否在现有子系统的基础上提供一个更简单的接口。 如果该接口能让客户端代码独立于众多子系统类， 那么你的方向就是正确的。
2. 在一个新的外观类中声明并实现该接口。 外观应将客户端代码的调用重定向到子系统中的相应对象处。 如果客户端代码没有对子系统进行初始化， 也没有对其后续生命周期进行管理， 那么外观必须完成此类工作。
3. 如果要充分发挥这一模式的优势， 你必须确保所有客户端代码仅通过外观来与子系统进行交互。 此后客户端代码将不会受到任何由子系统代码修改而造成的影响， 比如子系统升级后， 你只需修改外观中的代码即可。
4. 如果外观变得过于臃肿， 你可以考虑将其部分行为抽取为一个新的专用外观类。

优点：

菜鸟教程

• 减少系统相互依赖。
• 提高灵活性。
• 提高了安全性。

《图说设计模式》

• 对客户屏蔽子系统组件，减少了客户处理的对象数目并使得子系统使用起来更加容易。通过引入外观模式，客户代码将变得很简单，与之关联的对象也很少。
• 实现了子系统与客户之间的松耦合关系，这使得子系统的组件变化不会影响到调用它的客户类，只需要调整外观类即可。
• 降低了大型软件系统中的编译依赖性，并简化了系统在不同平台之间的移植过程，因为编译一个子系统一般不需要编译所有其他的子系统。一个子系统的修改对其他子系统没有任何影响，而且子系统内部变化也不会影响到外观对象。
• 只是提供了一个访问子系统的统一入口，并不影响用户直接使用子系统类。

缺点：

菜鸟教程

• 不符合开闭原则，如果要改东西很麻烦，继承重写都不合适。

《图说设计模式》

• 不能很好地限制客户使用子系统类，如果对客户访问子系统类做太多的限制则减少了可变性和灵活性。
• 在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。

使用注意：

与其他设计模式的联系：

《深入设计模式》

• 外观模式为现有对象定义了一个新接口， 适配器模式则会试图运用已有的接口。 适配器通常只封装一个对象， 外观通常会作用于整个对象子系统上。

• 当只需对客户端代码隐藏子系统创建对象的方式时， 你可以使用抽象工厂模式来代替外观。

• 享元模式展示了如何生成大量的小型对象， 外观则展示了如何用一个对象来代表整个子系统。

• 外观和中介者模式的职责类似： 它们都尝试在大量紧密耦合的类中组织起合作。

  • 外观为子系统中的所有对象定义了一个简单接口， 但是它不提供任何新功能。 子系统本身不会意识到外观的存在。 子系统中的对象可以直接进行交流。
  • 中介者将系统中组件的沟通行为中心化。 各组件只知道中介者对象， 无法直接相互交流。

• 外观类通常可以转换为单例模式类， 因为在大部分情况下一个外观对象就足够了。

• 外观与代理模式的相似之处在于它们都缓存了一个复杂实体并自行对其进行初始化。 代理与其服务对象遵循同一接口， 使得自己和服务对象可以互换， 在这一点上它与外观不同。

《图解设计模式》

Abstract Factory模式(第8章)
可以将Abstract Factory模式看作生成复杂实例时的Facade模式。因为它提供了“要想生成这个实例只需要调用这个方法就OK了”的简单接口。
Singleton模式(第5章)
有时会使用Singleton模式创建Facade角色。Mediator模式(第16章)
在Facade模式中，Facade角色单方面地使用其他角色来提供高层接口(API )。
而在Mediator模式中，Mediator角色作为Colleague角色间的仲裁者负责调停。可以说，Facade模式是单向的,而Mediator角色是双向的。

识别方法： 外观可以通过使用简单接口， 但将绝大部分工作委派给其他类的类来识别。 通常情况下， 外观管理着其所使用的对象的完整生命周期。

2. 使用实例

菜鸟教程

• 去医院看病，可能要去挂号、门诊、划价、取药，让患者或患者家属觉得很复杂，如果有提供接待人员，只让接待人员来处理，就很方便。
• JAVA 的三层开发模式。

《深入设计模式》

下面是一些核心 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 和其他一些类。

《重学Java设计模式》

标签：外观,--,接口,Facade,笔记,模式,设计模式,子系统
来源： https://blog.csdn.net/qq_37132495/article/details/121902202