设计模式: 结构型之外观模式(11)

外观模式概述

  • 外观模式(Facade Pattern)是一种结构型设计模式,它为复杂的系统、程序库或框架提供一个简单(但有限)的接口
  • 这种模式的核心理念是隐藏系统的复杂性,仅对外暴露一个简化的接口,使得外部代码能够更容易地与系统进行交互

外观模式实现步骤


1 ) 定义外观类

  • 这个类将作为系统与外部世界之间的中介。它内部会包含对系统内部复杂子系统的引用,并对外提供一组简化后的方法

2 )封装子系统

  • 外观类会将原本需要直接调用多个子系统的方法封装成单一的方法,或者将原本复杂的流程简化为一个或多个简单的操作。

3 )对外暴露接口

  • 外观类提供的接口应该足够简单,使得外部代码能够轻松理解并使用,而不需要深入了解系统内部的复杂细节

外观模式示例

// 子系统中的各个类
interface SubSystemA {
  operationA(): string;
}

interface SubSystemB {
  operationB(): string;
}

class ConcreteSubSystemA implements SubSystemA {
  operationA(): string {
    return 'Subsystem A operation executed';
  }
}

class ConcreteSubSystemB implements SubSystemB {
  operationB(): string {
    return 'Subsystem B operation executed';
  }
}

// 外观类,提供统一接口
class Facade {
  private subsystemA: SubSystemA;
  private subsystemB: SubSystemB;

  constructor() {
    this.subsystemA = new ConcreteSubSystemA();
    this.subsystemB = new ConcreteSubSystemB();
  }

  public facadeMethod(): string {
    const resultA = this.subsystemA.operationA();
    const resultB = this.subsystemB.operationB();

    // 可能还会包含其他子系统操作和组合逻辑
    return `Facade combined results: ${resultA} and ${resultB}`;
  }
}

// 客户端代码,使用外观类来调用子系统功能
function clientCode() {
  const facade = new Facade();
  const result = facade.facadeMethod();
  console.log(result); // 输出:Facade combined results: Subsystem A operation executed and Subsystem B operation executed
}

clientCode();
  • 在上述例子中,我们首先定义了两个子系统接口 SubSystemASubSystemB,以及它们各自的实现类 ConcreteSubSystemAConcreteSubSystemB
  • 接着,我们创建了一个名为 Facade 的外观类,它包含了对子系统的引用,并对外提供了 facadeMethod() 这个统一的方法
  • Facade 类的 facadeMethod() 方法中,它调用了子系统的多个方法(如 operationA()operationB()),并将它们的结果进行了整合或处理
  • 最后,在客户端代码中,客户端只需要直接与 Facade 类交互,无需关心子系统的具体实现细节,从而简化了客户端的使用,降低了耦合度

外观模式优缺点


1 )外观模式的优点主要有以下几个方面

  • 简化接口
    • 外观模式通过提供一个简化的接口,将复杂的子系统功能整合在一起,使得使用者可以更容易地调用这些功能
    • 这降低了系统的复杂性,提高了代码的可读性和易用性
  • 解耦合
    • 外观模式将子系统与外部系统进行解耦合,使得子系统的变化不会影响到使用它的外部系统
    • 外部系统只需要通过外观接口来访问子系统,不需要了解子系统内部的实现细节,这提高了系统的灵活性和可扩展性
  • 提高可维护性
    • 由于外观模式将系统的复杂性隐藏在一个单独的外观类中,使得代码更加清晰和易于维护
    • 当需要修改或扩展子系统功能时,只需要修改外观类,而不需要修改大量的外部代码

2 )外观模式也存在一些缺点

  • 不符合开闭原则
    • 在某些情况下,当添加新的子系统或移除现有子系统时,可能需要修改外观类或者客户端的代码
    • 这违背了开闭原则,即软件实体应当对扩展开放,对修改封闭
  • 可能导致系统过于复杂
    • 如果过度使用外观模式,可能会增加系统中类的数量,从而增加系统的复杂度
    • 此外,如果外观类设计得过于复杂,可能会引入新的复杂性,使得代码难以理解和维护
  • 可能影响性能
    • 如果外观类的实现不够高效,可能会影响系统的性能
    • 特别是在处理大量数据或执行复杂计算时,外观类可能成为性能瓶颈

3 ) 综上所述

  • 外观模式在简化接口、解耦合和提高可维护性方面具有显著优势,但也可能带来一些缺点
  • 因此,在使用外观模式时需要根据具体需求进行权衡和选择

相关推荐

  1. 设计模式: 结构外观模式(11)

    2024-04-12 07:56:02       40 阅读
  2. 设计模式结构模式外观模式

    2024-04-12 07:56:02       49 阅读
  3. GO设计模式——12外观模式结构

    2024-04-12 07:56:02       65 阅读

最近更新

  1. docker php8.1+nginx base 镜像 dockerfile 配置

    2024-04-12 07:56:02       94 阅读
  2. Could not load dynamic library ‘cudart64_100.dll‘

    2024-04-12 07:56:02       100 阅读
  3. 在Django里面运行非项目文件

    2024-04-12 07:56:02       82 阅读
  4. Python语言-面向对象

    2024-04-12 07:56:02       91 阅读

热门阅读

  1. 计算机网络

    2024-04-12 07:56:02       36 阅读
  2. MCU PAN184 说明书

    2024-04-12 07:56:02       39 阅读
  3. 敏捷开发是什么?敏捷开发的流程有什么?

    2024-04-12 07:56:02       38 阅读
  4. SQL Server数据库常用语句

    2024-04-12 07:56:02       33 阅读
  5. Qt多线程的学习

    2024-04-12 07:56:02       44 阅读
  6. 初识 QT

    初识 QT

    2024-04-12 07:56:02      34 阅读
  7. Liunx和Windows中重启MySql

    2024-04-12 07:56:02       31 阅读