适配器模式（Adapter Pattern）与外观模式（Facade Pattern）在 JS 库设计中的应用

好的，各位观众老爷们，欢迎来到“JavaScript奇巧淫技大赏”现场！我是今天的特邀嘉宾，人送外号“代码诗人”的程序猿小李飞刀（嗖！）。

今天咱们不聊框架大战，也不谈底层原理，就来聊聊两个经常被混淆，但实际上风马牛不相及的设计模式——适配器模式和外观模式。

想象一下，你手里拿着一个欧标插头，准备给你的 iPhone 充电。结果发现，咱们中国用的是国标插座！怎么办？难道要砸墙重装插座吗？当然不用，一个简单的“转换插头”就搞定了。

这个“转换插头”，就是我们今天要讲的“适配器模式”的完美化身！

而如果你要煮一杯咖啡，你需要烧水，研磨咖啡豆，冲泡等等一系列步骤。如果你嫌麻烦，直接买个全自动咖啡机，一键搞定！这个“全自动咖啡机”，就是“外观模式”的典型代表。

怎么样，是不是一下子就明白了？别急，好戏还在后头。

一、适配器模式：让格格不入的两人，喜结连理 💑

适配器模式，顾名思义，就是用来“适配”的。它的核心思想是：将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

1.1 适配器模式的适用场景

需要使用一个已存在的类，但其接口与你的需求不符。 比如，你的代码需要用到一个第三方库，但是这个库的接口和你现有的代码风格格格不入，这时候就可以用适配器模式来“翻译”一下。
想要创建一个可复用的类，该类可以与多个不相关的类协同工作。 比如，你需要连接不同的数据库，但是每个数据库的 API 都不一样，可以用适配器模式来统一接口，方便切换。
需要统一多个类的接口，使它们对外表现一致。 比如，你有很多个不同的支付方式，比如支付宝、微信支付、银行卡支付等等，可以用适配器模式来统一支付接口，方便调用。

1.2 适配器模式的实现方式

适配器模式主要有两种实现方式：

类适配器（继承）： 通过继承的方式来实现适配。适配器类继承需要适配的类，并实现目标接口。这种方式的缺点是只能适配一个类，而且只能适配 public 的方法。
对象适配器（组合）： 通过组合的方式来实现适配。适配器类包含一个需要适配的类的实例，并实现目标接口。这种方式更加灵活，可以适配多个类，而且可以适配 private 的方法。

1.3 代码示例（对象适配器）

假设我们有一个老旧的 LegacyCalculator 类，它只能进行简单的加法运算：

// 老旧的计算器类
class LegacyCalculator {
  add(num1, num2) {
    return num1 + num2;
  }
}

// 目标接口：现代计算器
class ModernCalculatorInterface {
  add(num1, num2) {}
  subtract(num1, num2) {}
  multiply(num1, num2) {}
  divide(num1, num2) {}
}

// 适配器类
class CalculatorAdapter extends ModernCalculatorInterface {
  constructor(legacyCalculator) {
    super();
    this.legacyCalculator = legacyCalculator;
  }

  add(num1, num2) {
    return this.legacyCalculator.add(num1, num2);
  }

  subtract(num1, num2) {
    throw new Error("LegacyCalculator does not support subtraction.");
  }

  multiply(num1, num2) {
    throw new Error("LegacyCalculator does not support multiplication.");
  }

  divide(num1, num2) {
    throw new Error("LegacyCalculator does not support division.");
  }
}

// 使用示例
const legacyCalculator = new LegacyCalculator();
const adapter = new CalculatorAdapter(legacyCalculator);

console.log(adapter.add(5, 3)); // 输出 8
try {
  adapter.subtract(5, 3); // 抛出错误
} catch (error) {
  console.error(error.message); // 输出 "LegacyCalculator does not support subtraction."
}

在这个例子中，CalculatorAdapter 就是一个适配器，它将 LegacyCalculator 的接口适配成了 ModernCalculatorInterface 的接口。这样，我们就可以在代码中使用 ModernCalculatorInterface 来操作 LegacyCalculator，而无需修改 LegacyCalculator 的代码。

1.4 适配器模式的优缺点

优点	缺点
提高了类的复用性：适配器模式可以让原本不能一起工作的类一起工作。	增加了代码的复杂度：适配器模式需要创建一个适配器类，这会增加代码的复杂度。
提高了系统的灵活性：适配器模式可以让你在不修改原有代码的情况下，适配新的类。	可能导致性能下降：适配器模式需要在运行时进行接口转换，这可能会导致性能下降。
符合开闭原则：适配器模式允许你在不修改现有代码的情况下扩展系统的功能。	对象适配器模式中，对适配类的方法进行了扩展，可能会导致原类的方法被覆盖，从而影响其他使用原类的代码。虽然可以通过一些技巧避免，例如采用函数式编程，但是会增加复杂度。

二、外观模式：一键开启你的懒人模式 😴

外观模式，也叫门面模式，是一种结构型设计模式。它的核心思想是：为子系统中的一组接口提供一个统一的入口。外观模式定义了一个高层接口，这个接口使得子系统更加容易使用。

2.1 外观模式的适用场景

需要为一个复杂的子系统提供一个简单的接口。 比如，你的代码需要操作一个复杂的第三方库，但是你只想使用其中几个常用的功能，这时候就可以用外观模式来封装一下。
客户程序与多个子系统之间存在很大的依赖性。 比如，你的代码需要调用多个不同的服务，但是你不想让代码和这些服务耦合在一起，可以用外观模式来解耦。
需要在层次化结构中，定义每层的入口。 比如，你的代码是一个分层架构，每一层都需要对外提供一些接口，可以用外观模式来定义每一层的入口。

2.2 外观模式的实现方式

外观模式的实现非常简单，只需要创建一个外观类，并在该类中封装子系统的调用即可。

2.3 代码示例

假设我们有一个复杂的子系统，包含多个类：

// 子系统类 1
class CPU {
  freeze() {
    console.log("CPU freezing...");
  }

  execute() {
    console.log("CPU executing...");
  }

  jump(position) {
    console.log(`CPU jumping to ${position}...`);
  }
}

// 子系统类 2
class Memory {
  load(position, data) {
    console.log(`Memory loading data ${data} from ${position}...`);
  }
}

// 子系统类 3
class HardDrive {
  read(lba, size) {
    console.log(`Hard Drive reading data from LBA ${lba}, size ${size}...`);
    return "OS Boot Sector Data";
  }
}

// 外观类
class ComputerFacade {
  constructor() {
    this.cpu = new CPU();
    this.memory = new Memory();
    this.hardDrive = new HardDrive();
  }

  start() {
    this.cpu.freeze();
    this.memory.load("0x0000", this.hardDrive.read(0, 512));
    this.cpu.jump("0x0000");
    this.cpu.execute();
  }
}

// 使用示例
const computer = new ComputerFacade();
computer.start();

在这个例子中，ComputerFacade 就是一个外观类，它封装了 CPU、Memory 和 HardDrive 的调用。这样，我们只需要调用 computer.start() 就可以启动电脑，而无需关心底层的细节。

2.4 外观模式的优缺点

优点	缺点
简化了接口：外观模式可以为复杂的子系统提供一个简单的接口，使得子系统更加容易使用。	不符合开闭原则：如果需要增加新的子系统，或者修改子系统的接口，就需要修改外观类，这违反了开闭原则。但是可以通过其他设计模式（如策略模式、工厂模式等）来解决这个问题。
解耦了客户端和子系统：外观模式可以降低客户端和子系统之间的依赖性，使得客户端可以独立于子系统进行修改。	可能会隐藏子系统的功能：外观模式可能会隐藏子系统的某些功能，使得客户端无法访问这些功能。
提高了系统的灵活性：外观模式可以让你在不修改客户端代码的情况下，替换子系统。	过度使用可能会导致系统变得复杂：如果为每个子系统都创建一个外观类，可能会导致系统变得复杂。

三、适配器模式 vs 外观模式：傻傻分不清楚？ 🤔

很多同学经常把适配器模式和外观模式搞混，因为它们都涉及到接口的转换。但实际上，它们的目的和侧重点完全不同。

特性	适配器模式	外观模式
目的	解决接口不兼容的问题，让原本不能一起工作的类一起工作。就像一个翻译器，把一种语言翻译成另一种语言。	简化接口，为复杂的子系统提供一个简单的入口。就像一个导游，带领游客参观景点，而不需要游客自己去研究路线和攻略。
侧重点	接口转换。适配器模式主要关注的是如何将一个类的接口转换成另一个类的接口。	简化使用。外观模式主要关注的是如何简化子系统的使用，让客户端更容易调用。
参与者数量	至少两个类：需要适配的类和目标接口。	多个类：外观类和子系统中的多个类。
关系	一对一：一个适配器类通常只适配一个类。	一对多：一个外观类通常封装多个子系统类。
意图	改变已存在接口，以适应新的需求。	提供一个统一的接口，隐藏系统的复杂性。
比喻	电源转换器，语言翻译器。	遥控器，自动售货机。

举个形象的例子：

适配器模式就像一个“万能插座”，它可以让你把各种不同类型的插头都插进去，然后转换成统一的电源输出。
外观模式就像一个“智能家居控制面板”，你可以通过它一键控制家里的灯光、温度、窗帘等等，而不需要了解每个设备的具体操作方法。

四、在 JS 库设计中的应用

适配器模式和外观模式在 JS 库设计中都有着广泛的应用。

4.1 适配器模式的应用

兼容不同的浏览器 API： 不同的浏览器对某些 API 的实现可能存在差异，比如 XMLHttpRequest 对象，可以用适配器模式来统一不同浏览器的 API，提供一个统一的接口。
封装第三方库的 API： 第三方库的 API 可能比较复杂或者不够友好，可以用适配器模式来封装一下，提供一个更简洁易用的接口。
处理不同的数据格式： 不同的数据源可能使用不同的数据格式，比如 JSON、XML 等，可以用适配器模式来统一数据格式，方便处理。

4.2 外观模式的应用

封装复杂的 DOM 操作： DOM 操作通常比较繁琐，可以用外观模式来封装一些常用的 DOM 操作，比如创建元素、添加事件监听器等，提供一个更简洁的接口。
封装复杂的动画效果： 动画效果通常需要多个步骤才能完成，可以用外观模式来封装一些常用的动画效果，比如淡入淡出、滑动等，提供一个更简洁的接口。
封装复杂的表单验证： 表单验证通常需要多个验证规则才能完成，可以用外观模式来封装一些常用的验证规则，比如邮箱验证、手机号验证等，提供一个更简洁的接口。

五、总结

适配器模式和外观模式都是非常实用的设计模式，它们可以帮助我们解决很多实际问题。

适配器模式： 当你需要让原本不能一起工作的类一起工作时，就用适配器模式。
外观模式： 当你需要为一个复杂的子系统提供一个简单的接口时，就用外观模式。

记住，设计模式不是银弹，不要为了用而用。在实际开发中，要根据具体的需求选择合适的设计模式，才能真正发挥设计模式的威力。

好了，今天的“JavaScript奇巧淫技大赏”就到这里。感谢各位观众老爷们的观看，我们下期再见！挥挥手 👋

发表回复 取消回复

发表回复取消回复