## 01、痛点

很多项目一开始都很简单。

比如一个订单通知服务，第一版只接入一家短信平台，代码直接写在 OrderService 里：

```java
public void sendSms(String phone, String content) {
    DefaultProfile profile = DefaultProfile.getProfile("cn-hangzhou", accessKeyId, accessKeySecret);
    IAcsClient client = new DefaultAcsClient(profile);
    CommonRequest request = new CommonRequest();
    request.setMethod(MethodType.POST);
    request.setDomain("dysmsapi.aliyuncs.com");
    request.setVersion("2017-05-25");
    request.setAction("SendSms");
    request.putQueryParameter("PhoneNumbers", phone);
    request.putQueryParameter("SignName", "某某科技");
    request.putQueryParameter("TemplateCode", "SMS_123456");
    request.putQueryParameter("TemplateParam", "{\"code\":\"" + content + "\"}");
    CommonResponse response = client.getCommonResponse(request);
    // 处理 response
}
```

后来业务说，我们也要支持腾讯云短信。

于是代码变成了这样：

```java
public void sendSms(String channel, String phone, String content) {
    if ("aliyun".equals(channel)) {
        // 阿里云 SDK 调用
    } else if ("tencent".equals(channel)) {
        // 腾讯云 SDK 调用
    }
}
```

再后来，邮件、企业微信、钉钉都来了。一个 Service 几百行，全是 if / else。不同厂商的 SDK 参数结构不一样，返回类型不一样，异常类型也不一样。业务层被这些细节污染得面目全非。

新增一种渠道就要改老代码，一个小需求要动五六个地方，新人根本不敢碰核心代码。

> 锐评：两个分支硬塞三个接口四个抽象类，那不叫设计模式，那叫给自己增加就业机会。

设计模式真正解决的，并不是“代码写得不高级”，而是“变化开始失控”。

当你的 Service 开始出现按类型分叉的 if / else，而每一个分支背后又是完全不同的第三方调用时，就应该意识到：变化点已经出现，是时候做职责拆分了。

## 02、是什么

设计模式，本质上是软件开发中反复出现的一类问题的“成熟解法”。

它有三个层次：

第一层：代码复用。
第二层：隔离变化。
第三层：管理复杂度。

它不是代码模板，也不是必须套用的公式，而是一种“职责如何拆、变化放在哪里”的思考方式。

适配器模式正是其中一个非常典型的代表。

适配器模式的核心目标：把一个已有接口转换成客户端期望的另一个接口，让原本不兼容的接口能够协同工作。

三个核心角色：

- Target：客户端期望的接口，例如我们定义的 SmsService。
- Adaptee：被适配者，即第三方 SDK 或遗留系统。
- Adapter：适配器，实现 Target，内部持有 Adaptee，负责转换调用。

字符图：

```
业务层
  |
  v
SmsService (Target)
  |
  v
AliyunSmsAdapter (Adapter) ---- AliyunSmsClient (Adaptee)
```

对象适配器和类适配器的区别：

- 对象适配器：通过组合持有 Adaptee 实例。Java 中主流做法，因为不受单继承限制，更灵活。
- 类适配器：通过继承 Adaptee 实现 Target。Java 中较少使用，因为它要求 Adaptee 不是 final 类，且会暴露父类方法。

适配器在第三方 SDK、遗留系统接入中的价值非常大。它让业务层只依赖自己定义的接口，而不用关心外部接口长什么样。

## 03、为什么

很多开发者学过设计模式，却在真实项目中不会用。

常见三个误区：

误区一：先记模式，再找地方套。
误区二：看到 if / else 就认为必须上策略模式。
误区三：抽象层越多，架构越高级。

判断设计模式是否值得使用的几个标准：

1. 变化是否真实存在？
2. 变化是否会持续增加？
3. 修改是否频繁影响旧逻辑？
4. 多个实现是否存在稳定公共结构？
5. 引入模式后，理解成本是否低于原来的维护成本？

可以看一个简单公式：

```
模式收益 = 未来变化成本降低 / 当前抽象复杂度增加
```

设计模式不是减少代码，而是降低未来修改代码的风险。

> 锐评：十行代码解决的问题，不要写成一场架构发布会。

很多项目里，一个通知模块只有两种渠道，而且未来三年都不会增加。你硬拆出五个接口、十个类，解决的并不是扩展性问题，而是阅读理解问题。

适配器模式尤其容易被滥用。当第三方接口之间差异不大时，强行加一层 Adapter 反而让链路变长。模式的价值是隔离真正的差异，而不是制造形式上的“统一”。

## 04、架构

设计模式不应该按 GoF 23 种逐个记忆，而应该按“开发问题”分类。

字符版设计模式问题地图：

```
变化类型一：对象怎么创建？
→ 工厂 / 建造者

变化类型二：多个实现怎么切换？
→ 策略

变化类型三：流程怎么复用？
→ 模板方法

变化类型四：多个节点怎么串起来？
→ 责任链

变化类型五：外部系统怎么接进来？
→ 适配器

变化类型六：功能怎么动态叠加？
→ 装饰器

变化类型七：状态不同怎么改变行为？
→ 状态模式
```

完整思路：

```
需求变化
↓
变化点识别
↓
职责拆分
↓
模式选择
↓
接口稳定
↓
实现扩展
```

适配器解决的问题很明确：“外部系统怎么接进来”。当你发现业务代码里到处都是第三方 SDK 的 import 和参数转换时，这个变化点就值得隔离。

## 05、实战

### 一、业务场景

订单通知服务需要支持短信发送，未来可能接入不同短信厂商（阿里云、腾讯云）。业务层只关心“发短信”，不关心厂商细节。

### 二、第一版代码

直接在 OrderService 里调用阿里云 SDK，参数硬编码，异常处理堆积，像上面 01 里的代码一样。

### 三、代码开始失控

接入腾讯云后，出现 if / else 分支。两个 SDK 的请求参数结构不同：阿里云用 CommonRequest，腾讯云用 SmsRequest；返回结构也不同：一个返回 RequestId，一个返回 MessageId。业务层开始出现各种转换和兼容代码，重复代码大量复制。

### 四、模式重构

第一步，定义统一接口：

```java
public interface SmsService {
    SmsResult send(SmsRequest request);
}
```

第二步，定义业务层自己的请求和结果对象：

```java
public class SmsRequest {
    private String phone;
    private String signName;
    private String templateCode;
    private Map<String, String> params;
    // getters/setters
}

public class SmsResult {
    private boolean success;
    private String messageId;
    private String errorMessage;
    // getters/setters
}
```

第三步，编写阿里云适配器：

```java
@Component("aliyunSmsService")
public class AliyunSmsAdapter implements SmsService {
    private final AliyunSmsClient aliyunSmsClient;

    public AliyunSmsAdapter(AliyunSmsClient aliyunSmsClient) {
        this.aliyunSmsClient = aliyunSmsClient;
    }

    @Override
    public SmsResult send(SmsRequest request) {
        AliyunRequest aliyunRequest = AliyunRequest.builder()
                .phone(request.getPhone())
                .signName(request.getSignName())
                .templateCode(request.getTemplateCode())
                .params(request.getParams())
                .build();
        AliyunResponse response = aliyunSmsClient.send(aliyunRequest);
        return new SmsResult(response.isSuccess(), response.getRequestId(), response.getErrorMsg());
    }
}
```

腾讯云适配器类似，实现 SmsService，内部把业务模型转换为腾讯云 SDK 需要的参数。

第四步，业务层通过 Map 注入自动选择适配器：

```java
@Service
public class NotificationService {
    private final Map<String, SmsService> smsServiceMap;

    public NotificationService(Map<String, SmsService> smsServiceMap) {
        this.smsServiceMap = smsServiceMap;
    }

    public void sendSms(String channel, SmsRequest request) {
        SmsService smsService = smsServiceMap.get(channel + "SmsService");
        if (smsService == null) {
            throw new IllegalArgumentException("Unsupported sms channel: " + channel);
        }
        smsService.send(request);
    }
}
```

这里利用了 Spring 的依赖注入：Map<String, SmsService> 会自动注入所有实现 SmsService 的 Bean，key 是 Bean 名称。业务层不再 import 任何厂商 SDK，只依赖自己的接口。

### 五、结构变化

改造前：

```
OrderService
|
+-- if aliyun -> 阿里云SDK
+-- if tencent -> 腾讯云SDK
+-- if email -> ...
```

改造后：

```
OrderService
|
v
NotificationService
|
v
SmsService (Map)
|
+-- AliyunSmsAdapter -> AliyunSmsClient
+-- TencentSmsAdapter -> TencentSmsClient
```

### 六、收益

- 新增短信厂商只需新增一个 Adapter 类并注册到 Spring 容器，业务层零改动。
- 业务层只依赖 SmsService 接口，不再 import 任何厂商 SDK。
- 单元测试可以 mock SmsService，不用真正发短信。
- 职责单一，每个 Adapter 只负责一个厂商适配。

### 七、代价

- 类数量增加：多了一个接口、多个 Adapter、请求和结果对象。
- 阅读链路变长：需要理解 Spring 的 Map 注入机制。
- 如果两个厂商的适配逻辑差异巨大，接口可能需要频繁调整。

### 八、什么时候不要用

- 只有一家短信厂商，且未来没有明确接入第二家的计划，不要搞一套抽象。
- 两家厂商的 SDK 结构几乎一样，可以直接用同一个包装，不必强行适配。
- 适配器应该解决接口不兼容，而不是给你提供一个“看起来整洁”的地方堆 if / else。

口诀：

> “不是给第三方接口重新起名字，而是保护自己的业务模型不被外部接口污染。”

> 锐评：如果为了适配器而适配器，把两个几乎相同的 SDK 硬包出两套 Adapter，你得到的不是扩展性，而是重复代码。

## 06、洞见

适配器模式只是设计模式中的一个点，但它能帮我们看透几个重要问题。

洞见一：设计模式真正关注的是“变化”，不是“类”。
洞见二：好的抽象通常来自重复出现的变化，而不是提前想象。
洞见三：设计模式最重要的价值是降低修改半径。
洞见四：架构能力的重要体现，不是能设计多少层，而是知道什么时候不需要设计。
洞见五：很多 Spring 框架设计本身就是设计模式的大型实践。

例如：

- Spring BeanFactory → 工厂模式
- ApplicationListener → 观察者模式
- JdbcTemplate → 模板方法
- HandlerInterceptor → 责任链思想
- AOP → 代理思想

这些不是巧合。框架作者正是在解决大量真实问题后，才沉淀出这些结构。它们和我们在业务代码里使用设计模式的本质是一样的：把变化隔离起来，让稳定的部分保持简单。

> 锐评：初级开发者喜欢把代码写出来，高级开发者开始考虑怎么变化，架构师最终考虑的是：哪些地方根本不值得抽象。

## 07、行动

设计模式不是背出来的，是重构出来的。

建议分三个阶段。

第一阶段：先认识 5 个最常用模式——策略、工厂、模板方法、责任链、适配器。

第二阶段：从自己的项目里找坏味道。每天找一个：大 if / else、重复流程、第三方接口污染、复杂对象创建、状态判断。

第三阶段：尝试重构。每次重构都回答五个问题：

1. 变化点是什么？
2. 不使用模式会怎样？
3. 使用模式增加了什么复杂度？
4. 下一次新增需求，需要修改几个地方？
5. 新人是否更容易理解？

七天实践计划：

```
Day 1：找一个超过 5 个分支的 if / else。
Day 2：用策略模式重构。
Day 3：找一段重复业务流程。
Day 4：尝试模板方法。
Day 5：找一个第三方接口封装。
Day 6：用适配器隔离。
Day 7：重新评估：哪些重构其实没有必要？
```

适配器模式的训练重点就是 Day 5 和 Day 6：找到一个已经接入的第三方接口，看看它有没有污染你的业务代码。如果有，定义自己的接口，把第三方调用关进 Adapter。

## 08、小结

> 设计模式不是为了让代码看起来高级，而是为了让下一次需求变化时，你不用推倒重来。

适配器模式只是其中一个工具，但它教会我们一件事：当你发现外部接口的差异开始侵蚀业务逻辑时，不要急着加分支，而是先定义自己的接口，把变化隔离出去。

真正值得学习的不是 23 个名字，而是看到变化、识别变化、隔离变化的能力。

如果读完这篇文章，你少写了一个 500 行 if / else，这篇文章就算没有白写。

## 09、链接与概念说明

- GoF：Gang of Four，指 Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides 四人。他们在 1995 年出版《Design Patterns: Elements of Reusable Object-Oriented Software》，提出了 23 种经典设计模式。
- 创建型模式：解决“对象怎么创建”，把创建逻辑与使用逻辑解耦。
- 结构型模式：解决“类或对象如何组织关系”，让系统结构更清晰、更灵活。
- 行为型模式：解决“对象之间如何协作和分配职责”，让行为变化更容易管理。
- SOLID 原则与设计模式的关系：设计模式是实现 SOLID 原则的具体手段之一。例如单一职责原则常通过拆分 Adapter 或 Strategy 实现，开闭原则则常依赖策略模式、模板方法、适配器等扩展点。
- 开闭原则：对扩展开放，对修改关闭。设计模式的价值很大程度上就是帮你做到“新增功能时不修改已有代码”。
- 推荐继续阅读：GoF《Design Patterns》、Eric Freeman 等《Head First Design Patterns》、Refactoring Guru 网站。这些资料能帮你从原理层面补全设计模式知识，但真正的判断力只能在重构实践中获得。

比如一个订单通知服务，第一版只接入一家短信平台，代码直接写在 OrderService 里：

适配器模式实战：接入两家短信 SDK 后，我如何让业务层彻底无感知

一个订单通知服务接入两家短信 SDK 后，业务层被厂商接口细节污染。本文通过引入统一 SmsService 和适配器隔离差异，重构到可扩展，并给出何时不该用适配

架构师

编程语言

架构设计

开发工具

适配器模式在Java项目中隔离第三方短信SDK差异，通过统一SmsService接口、Adapter类及Spring依赖注入实现业务零侵入扩展。文中给出代码重构前后对比、模式适用条件与收益代价，并强调设计模式核心是识别变化点，避免过度抽象。适合处理多渠道通知、接口不兼容场景的架构优化。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

适配器模式实战：接入两家短信 SDK 后，我如何让业务层彻底无感知-腾讯云开发者社区-腾讯云

适配器模式实战：接入两家短信 SDK 后，我如何让业务层彻底无感知

适配器模式实战：接入两家短信 SDK 后，我如何让业务层彻底无感知

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐