设计模式——外观模式

文章目录

• • • 使用外观模式的场景
    • 什么时候需要重新编写系统而不是使用外观模式
    • 举例

      外观模式（Facade Pattern）是一种结构型设计模式，它提供了一个统一的接口，用来访问子系统中的一群接口。外观模式定义了一个高层接口，使得这一子系统更加容易使用。通过使用外观模式，客户端不需要了解子系统的复杂性，只需与外观类进行交互，从而简化了代码。

      
      （图片来源网络，侵删）

      使用外观模式的场景

      1. 简化复杂系统的使用：

         • 如果你有一个复杂的系统，它包含了多个模块或子系统，客户端需要与这些模块或子系统进行交互。外观模式可以提供一个简单的接口，隐藏系统的复杂性，使得客户端可以更容易地使用系统。
         • 例如，一个多媒体系统可能包含视频播放器、音频播放器、字幕管理等子系统。通过引入一个外观类，客户端可以通过简单的接口来播放多媒体文件，而无需关心各个子系统的细节。

         • 松散耦合：

           • 外观模式可以帮助降低子系统与客户端之间的耦合。客户端只需要与外观类交互，而不需要直接依赖具体的子系统。这有助于提高系统的灵活性和可维护性。
           • 例如，在一个电商平台中，订单处理可能涉及库存管理、支付处理、物流管理等多个子系统。通过引入一个订单外观类，客户端可以通过这个外观类来处理订单，而不需要了解各个子系统的实现细节。

      什么时候需要重新编写系统而不是使用外观模式

      1. 系统的核心逻辑需要重构：

         • 如果系统的核心业务逻辑存在根本性的设计缺陷或性能瓶颈，仅仅引入外观模式可能无法解决问题。在这种情况下，可能需要重新设计和实现系统。
         • 例如，如果一个旧的库存管理系统因为使用了过时的算法导致性能极差，无论如何封装和简化接口，都无法满足新的性能要求，此时需要对核心算法和数据结构进行重构。

         • 技术栈和架构的彻底改变：

           • 如果系统需要迁移到新的技术栈或架构（例如从单体架构迁移到微服务架构），那么单纯使用外观模式无法实现这种转换，需要重新设计和编写系统。
           • 例如，一个旧的企业资源规划（ERP）系统最初是用COBOL语言编写的，现在需要迁移到基于云计算的微服务架构。在这种情况下，可能需要重新编写系统，而不是简单地封装旧系统的接口。

           • 累积的技术债务过多：

             • 如果系统经过多年维护和修改，累积了大量技术债务，代码难以维护和扩展，且频繁出现bug。此时，与其继续在不稳定的基础上添加外观模式，不如重新设计和实现系统。
             • 例如，一个老旧的客户关系管理（CRM）系统，随着业务需求的变化，系统变得复杂且难以维护，新的需求无法高效实现。此时，重新设计一个现代化的CRM系统可能是更好的选择。

      举例

      重新编写系统的例子：

      假设你有一个老旧的银行交易系统，最初设计时没有考虑到现代网络安全协议。随着安全要求的提高，系统需要支持新的加密标准和多因素认证。由于原系统代码复杂且安全漏洞多，继续在其上修改会非常困难。此时，重新设计和编写一个符合现代安全标准的交易系统是更好的选择。

      使用外观模式的例子：

      假设你有一个电子邮件营销系统，包含邮件发送、统计分析、用户管理等多个子系统。为了简化营销人员的使用，你可以设计一个外观类，提供统一的接口进行邮件营销活动的管理。营销人员不需要了解每个子系统的复杂细节，只需使用外观类提供的简单接口即可完成工作。