实现依赖可互换的封装设计模式属于适配器还是外观模式？

你实现的makeRequest属于外观模式（Facade Pattern），并不是适配器模式，二者的区别对应你的场景可以很清晰区分：

• 外观模式的核心目标是做内外逻辑解耦：对外暴露一个统一、简单的通用入口，把内部所有复杂的实现细节、依赖差异全部封装在入口内部。外部调用方完全不需要关心内部逻辑怎么跑、用了什么第三方依赖，只需要按照约定跟这个统一入口交互就行。你现在的设计完全匹配这个特征：业务模块只需要调用makeRequest传对应参数，不需要感知底层用的是axios、superagent还是原生fetch，后续更换请求库只需要修改这一个函数的内部实现，外部代码零改动，这就是外观模式最典型的落地场景。
• 适配器模式的核心目标是做接口兼容：它是用来解决「两个已有的接口格式不匹配，没法直接对接」的问题，本质是做一层格式转换，把一个接口的入参、出参、调用方式包装成调用方预期的形态，本身不承担统一入口、简化调用链路的作用。举个和你场景相关的例子：如果你之前的业务代码全是直接调用axios的axios.get/axios.post等原生方法，现在要切到fetch，你写了一层兼容代码，让这层代码的方法名、参数格式、返回值结构和原来的axios完全一致，老代码不用改一行就能直接切到fetch，这层兼容转换的代码才是适配器。

实际开发中两个模式经常搭配使用：如果你后续为了适配多个请求库，给axios、superagent、fetch分别写了小段转换逻辑，把它们各自不同的调用方式统一对齐成makeRequest内部约定的标准格式，这每一段针对单个库的转换逻辑就是适配器，而对外暴露的makeRequest入口本身依然是外观层。

内容的提问来源于stack exchange，提问作者J Seabolt