「软件设计模式杂谈🤔」和后端吵架失败了，于是乎我写了个适配器模式

Hi! 这里是JustHappy ，作为一个前端开发者，更是软件工程师，软件设计模式咱必须要接触吧，所以来吧！一起来聊聊！我们从适配器模式开始吧！

什么玩意儿是"适配器模式"？

我们先来查查百科吧！（以下内容引用自维基百科）

在设计模式中，适配器模式 （英语：adapter pattern）有时候也称包装样式或者包装（英语：wrapper）。将一个类的接口转接成用户所期待的。一个适配使得因接口不兼容而不能在一起工作的类能在一起工作，做法是将类自己的接口包裹在一个已存在的类中。

主要有两类吧：

🧩 类适配器模式（基于继承）

🧩 对象适配器模式（基于组合）

是不是有些不讲人话，我们来拆解一下吧：

试想一个场景！🤯

又是一个蛋疼的下午，我们要进行前后端联调，出现什么问题呢？后端同学给的接口实在是丑陋，但是咱这"前端切图仔"，长期处于鄙视链的底端，愣是没有在 "吵架环节" 说服后端修改接口，怎么办呢？那我们自己来把这个接口变得不那么丑陋吧

注：这里后端提供的接口不符合我们的预期，所以我们要处理....

怎么办呢？

假设后端传递过来的接口长下面这样

js 复制代码

{
  "user_name": "Simon",
  "user_age": 25,
  "user_status": 1
}

可是你页面中已经写好了对应的逻辑，需要的数据结构应该是下面这样，尴尬了，字段名也不对，类型还对不上。

js 复制代码

IUser = {
  name: string
  age: number
  isActive: boolean
}

怎么办？总有一个人需要做出让步吧...... 既然我们吵架吵输了

那就使用适配器模式吧！

话不多说，我们在这实现一个最简单的适配器

js 复制代码

// 后端返回的数据
const backendData = {
  user_name: "Simon",
  user_age: 25,
  user_status: 1
}

// 我们期望使用的数据结构是这样子的：
/*
{
  name: "Simon",
  age: 25,
  isActive: true
}
*/

// 适配器函数：把后端数据"翻译"成我们喜欢的格式
function adaptUser(data) {
  return {
    name: data.user_name,
    age: data.user_age,
    isActive: data.user_status === 1
  }
}

// 使用适配器
const user = adaptUser(backendData)

console.log(user)
// 输出：{ name: "Simon", age: 25, isActive: true }

🧬 类适配器 vs 对象适配器：到底差在哪？

简单点讲：

类适配器 通过继承实现，适合在强类型语言里搞搞（比如 Java、C#）。
对象适配器 用的是组合（组合优于继承听说过吧~），更适合咱 JS/TS 世界。

所以我们前端用得最多的，其实就是对象适配器了。写个函数转换一下，就能干翻一堆奇怪数据结构。

做个简单的总结吧

✨ 总结一下

适配器模式就像我们生活中的万能插头，左手接老式接口，右手接新式需求，居中搞桥梁。在实际项目中，特别是做前后端联调时，简直不要太常见！

📌 你可以用它来：

接老旧系统的接口
封装第三方库的输出
或者在多人协作时保护自己的"数据整洁癖"