设计模式(结构型)-外观模式-CSDN博客

本文链接：https://blog.csdn.net/weixin_41645817/article/details/147066163

定义

外观模式，作为一种结构型设计模式，旨在为子系统中的一组接口提供一个统一且一致的高层接口，使得这些子系统能够以更加便捷、易用的方式被外界访问。其核心要义在于，通过定义一个外观类，将原本复杂的子系统内部细节进行封装与隐藏，为客户端提供一个简洁、统一的调用入口。客户端只需与外观类进行交互，而无需深入了解子系统内部的复杂实现逻辑，从而极大地降低了客户端使用子系统的难度与复杂度。

从本质上讲，外观模式的实现核心在于由外观类来保存各个子系统的引用。通过这种方式，外观类能够将客户端的请求委派到相应的子系统中去，实现由一个统一的外观类来包装多个子系统类的功能。如此一来，客户端只需要引用这个外观类，便可以通过外观类来调用各个子系统中的方法，进而实现了客户端与子系统之间的解耦，让整个系统的结构更加清晰、易于维护。

例如，在一个大型的电商系统中，涉及到库存管理、订单处理、支付结算、物流配送等多个复杂的子系统。对于前端开发人员而言，直接与这些子系统进行交互无疑是一项艰巨的任务，需要了解各个子系统的接口规范、业务逻辑以及数据格式等诸多细节。而引入外观模式后，我们可以创建一个电商外观类（如 EcommerceFacade），该类内部持有库存管理子系统、订单处理子系统、支付结算子系统以及物流配送子系统的引用。前端开发人员只需通过调用 EcommerceFacade 类的方法，如 placeOrder（下单）、checkStock（查询库存）等，即可完成与多个子系统的交互，无需关心各个子系统的具体实现细节。这样不仅简化了前端开发人员的工作，还降低了系统的耦合度，使得各个子系统可以独立进行升级与维护。

与适配器模式相比，虽然两者都涉及到对接口的处理，但它们的设计意图却截然不同。适配器模式主要用于将一个对象的接口转换为另一个客户端所期望的接口，其目的在于解决接口不兼容的问题；而外观模式则是将一群对象的接口进行包装，提供一个统一的接口来简化客户端的调用，其重点在于隐藏子系统的复杂性，提高系统的易用性。

类图

角色

外观模式的类图通常包含以下几个关键元素：

门面（Facade）角色：作为外观模式的核心角色，门面类为客户端提供了一个统一的接口，用于访问子系统中的各个功能。它内部持有一个或多个子系统角色的引用，并负责将客户端的请求委派到相应的子系统中进行处理。在类图中，门面类与子系统角色之间存在关联关系。
子系统（subsystem）角色：子系统角色由一个或多个类组成，每个类实现了特定的功能模块。这些子系统类相互协作，共同完成整个系统的复杂业务逻辑。子系统类既可以被客户端直接调用，也可以被门面角色调用。然而，子系统类并不知道门面类的存在，它们只关注自身功能的实现。在类图中，子系统角色通常以一组相关类的集合形式呈现。
客户端（Client）角色：客户端是使用系统功能的外部对象。在外观模式中，客户端通过调用门面类的接口来访问子系统的功能，而无需直接与子系统类进行交互。在类图中，客户端与门面类之间存在依赖关系。

角色详解

门面（Facade）角色：门面类就如同一个系统的 “前台接待员”，它负责接收客户端的请求，并将这些请求转发给相应的子系统进行处理。门面类不仅提供了一个统一的接口，简化了客户端与子系统之间的交互，还可以对客户端的请求进行预处理、后处理以及错误处理等操作。例如，在一个视频播放系统中，门面类 VideoPlayerFacade 可以提供 playVideo（播放视频）、pauseVideo（暂停视频）、stopVideo（停止视频）等简单易懂的接口。当客户端调用 playVideo 方法时，VideoPlayerFacade 内部会依次调用视频解码子系统、音频解码子系统、播放控制子系统等相关子系统的方法，完成视频的播放功能。同时，VideoPlayerFacade 还可以在播放视频之前进行一些权限验证、资源加载等预处理操作，在播放结束后进行资源释放等后处理操作。
子系统（subsystem）角色：子系统角色是实现系统具体功能的核心部分。每个子系统都专注于完成特定的业务功能，它们相互独立又相互协作。例如，在上述视频播放系统中，视频解码子系统负责将视频文件的编码格式转换为可播放的图像数据；音频解码子系统负责将音频文件的编码格式转换为可播放的声音数据；播放控制子系统则负责控制视频和音频的播放进度、暂停、停止等操作。这些子系统各自完成自己的任务，通过门面类的协调与整合，共同为客户端提供完整的视频播放服务。对于子系统而言，门面类仅仅是另一个客户端，它们并不关心门面类的存在，只专注于自身功能的实现与优化。
客户端（Client）角色：客户端是外观模式的使用者，它通过调用门面类的接口来获取系统的功能服务。客户端无需了解子系统的内部结构与实现细节，只需要知道门面类提供的接口即可。这使得客户端的代码变得简洁明了，降低了与子系统之间的耦合度。例如，在一个音乐播放器应用中，用户界面（客户端）只需要调用 MusicPlayerFacade 的 playMusic（播放音乐）、nextSong（播放下一首歌曲）、previousSong（播放上一首歌曲）等接口，就可以实现音乐的播放控制功能，而无需关心音乐解码、音频输出等子系统的具体实现。

优缺点

优点

简化接口，降低使用难度：外观模式对客户端屏蔽了子系统组件的复杂性，客户端只需与外观类进行交互，无需了解子系统内部的众多接口与复杂逻辑。这大大减少了客户端所需处理的对象数目，使得子系统的使用变得更加容易。例如，在一个企业级的财务管理系统中，涉及到财务报表生成、税务计算、成本核算等多个复杂的子系统。通过引入外观模式，创建一个 FinanceFacade 类，为客户端提供诸如 generateFinancialReport（生成财务报表）、calculateTax（计算税务）、computeCost（核算成本）等简单统一的接口。客户端开发人员只需调用这些接口，即可完成相应的财务管理功能，无需深入了解各个子系统的复杂实现细节，极大地提高了开发效率。
实现松耦合，增强系统灵活性：外观模式实现了子系统与客户端之间的松耦合关系。由于客户端只与外观类交互，而不直接依赖于子系统，当子系统的内部实现发生变化时，只要外观类的接口保持不变，就不会影响到客户端的代码。同样，当客户端的需求发生变化时，也可以通过修改外观类来适应变化，而不会对各个子系统造成影响。这种松耦合的设计使得子系统和客户端都具有更高的独立性和可维护性，便于系统的扩展与升级。例如，在一个在线购物系统中，如果支付子系统需要更换支付渠道（如从支付宝支付改为微信支付），由于客户端与支付子系统之间通过外观类进行解耦，只需在外观类中对支付接口进行相应的调整，而不会影响到购物车管理、订单处理等其他子系统以及客户端的代码。
子系统独立，便于维护与扩展：外观模式使得一个子系统的修改对其他子系统没有任何影响，而且子系统的内部变化也不会影响到外观对象。每个子系统都可以独立进行开发、测试、维护和升级，互不干扰。这有利于提高开发效率，降低系统维护成本。例如，在一个游戏开发项目中，游戏的图形渲染子系统、物理引擎子系统、人工智能子系统等可以由不同的开发团队分别负责开发与维护。通过外观模式，各个子系统之间相互独立，当图形渲染子系统需要升级以支持更高的画质时，不会对物理引擎子系统和人工智能子系统造成影响，各个团队可以专注于自己负责的子系统的优化与扩展。

缺点

限制客户端直接访问子系统的灵活性：外观模式虽然简化了客户端与子系统之间的交互，但在某些情况下，它不能很好地限制客户端直接使用子系统类。如果客户端需要直接访问子系统类的某些特殊功能，而外观类又没有提供相应的接口，那么就会给客户端带来不便。此外，如果对客户端访问子系统类做太多的限制，虽然可以提高系统的安全性和稳定性，但也会在一定程度上减少系统的可变性和灵活性。例如，在一个复杂的科研计算系统中，某些专业用户可能需要直接调用底层的数学计算子系统的特定算法进行深入的数据分析，而外观类可能没有提供这些特殊算法的接口，这就限制了用户的使用灵活性。
可能违背开闭原则：如果设计不当，当需要增加新的子系统时，可能需要修改外观类的源代码。这违背了开闭原则，即软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。例如，在一个智能家居控制系统中，最初的外观类 SmartHomeFacade 只封装了灯光控制子系统、窗帘控制子系统和空调控制子系统。当系统需要增加一个新的安防监控子系统时，如果外观类的设计没有考虑到可扩展性，就可能需要修改 SmartHomeFacade 类的代码，添加对安防监控子系统的引用和相关接口，这会增加系统维护的难度和风险。

适用场景

为复杂子系统提供简单统一入口：当系统中存在一系列复杂的子系统，而客户端只需要使用其中的部分功能，并且希望通过一个简单统一的接口来访问这些功能时，外观模式是一个理想的选择。例如，在一个大型的企业资源规划（ERP）系统中，包含了人力资源管理、财务管理、供应链管理、生产管理等多个复杂的子系统。对于企业的普通员工而言，他们可能只需要使用与自己工作相关的部分功能，如查看工资单（涉及财务管理子系统）、请假申请（涉及人力资源管理子系统）等。通过创建一个 ERPFacade 类，为员工提供诸如 viewPayroll（查看工资单）、applyLeave（请假申请）等简单统一的接口，员工只需调用这些接口，即可完成相应的操作，无需了解各个子系统的复杂细节。
解耦客户端与子系统，提高子系统独立性：当客户端程序与多个子系统之间存在很大的依赖性，导致系统的耦合度较高时，引入外观模式可以将子系统与客户端解耦，从而提高子系统的独立性和可移植性。例如，在一个移动应用开发项目中，应用程序需要与多个后端服务子系统进行交互，如用户认证子系统、数据存储子系统、推送通知子系统等。如果应用程序直接与这些子系统进行交互，会使得应用程序与后端服务子系统之间的耦合度非常高，不利于系统的维护与升级。通过创建一个 AppFacade 类，将应用程序与后端服务子系统之间的交互进行封装，应用程序只需与 AppFacade 类进行交互，即可实现与各个后端服务子系统的通信，大大降低了应用程序与后端服务子系统之间的耦合度，提高了后端服务子系统的独立性和可移植性。
降低层次化结构中系统层间耦合度：在层次化结构的系统中，可以使用外观模式定义系统中每一层的入口。层与层之间不直接产生联系，而是通过外观类建立联系，这样可以有效地降低层之间的耦合度。例如，在一个典型的三层架构（表现层、业务逻辑层、数据访问层）的 Web 应用系统中，表现层负责与用户进行交互，展示页面和接收用户输入；业务逻辑层负责处理业务规则和数据处理；数据访问层负责与数据库进行交互，执行数据的增删改查操作。通过在每一层定义外观类，如 PresentationFacade（表现层外观类）、BusinessFacade（业务逻辑层外观类）、DataAccessFacade（数据访问层外观类），表现层通过 PresentationFacade 与业务逻辑层进行交互，业务逻辑层通过 BusinessFacade 与数据访问层进行交互，层与层之间通过外观类进行解耦，使得系统的层次结构更加清晰，维护更加方便。当业务逻辑层的实现发生变化时，只需修改 BusinessFacade 类的代码，而不会影响到表现层和数据访问层的代码。

总结

综上所述，外观模式作为一种强大的设计模式，在简化系统结构、降低耦合度、提高系统易用性等方面具有显著的优势。通过合理运用外观模式，我们能够更加高效地构建复杂的软件系统，提升系统的可维护性与扩展性。然而，在使用外观模式时，我们也需要充分考虑其可能带来的缺点，并根据具体的业务需求和系统架构进行权衡与设计，以确保外观模式能够发挥出最大的价值。