.NET开发中的适配器模式：让系统集成更丝滑的秘密武器
适用人群：.NET开发者、软件架构师、对设计模式和系统集成有深入兴趣的技术同仁。
引言：异国插座的启示
想象下，你刚到一个新国家，兴冲冲地准备给你的笔记本电脑充电，却发现插头根本插不进墙上的插座！😱 这时候，你只需要一个电源适配器，一切就迎刃而解——无需改造插座或电脑，适配器充当了“翻译”，让两者无缝协作。
软件集成中也经常遇到类似问题：现代应用需要对接遗留系统、第三方服务，接口风格南辕北辙。如何让它们握手言和？这正是适配器（Adapter）模式大显身手的地方。
为什么需要适配器模式？
场景一：新旧系统的“对话”
假设你的.NET项目采用REST API架构，但公司老掉牙的支付网关只支持SOAP。重写任何一端都代价高昂且风险大。怎么办？用“适配器”将REST请求翻译成SOAP请求，再把响应转回来。两边都不用改动，轻松集成！
场景二：多云存储统一接口
你要同时支持Amazon S3、Azure Blob Storage和Google Cloud Storage，每家SDK都不一样。如果每次都写一套调用逻辑，维护简直灾难。如何优雅解决？定义统一接口，各云厂商SDK实现自己的适配器即可！
什么是适配器模式？
定义：适配器模式是一种结构型设计模式，通过引入一个“适配器”类，将一个接口转换为另一个接口，让原本因接口不兼容无法协作的类能够一起工作。
简单来说，就是“翻译官”或“中间人”。
适配器模式的两种实现方式
1. 对象适配器模式（Object Adapter Pattern）
- 实现方式：适配器通过“组合”持有被适配对象，并在方法内部委托调用。
- 优势：不需要修改原有类，灵活可复用，适合C#等不支持多继承的语言。
- 典型场景：对接第三方库、遗留代码。
代码示例
// 目标接口
public interface IPrinter {
void Print(string document);
}
// 遗留类
public class LegacyPrinter {
public void PrintDocument(string doc) { /* ... */ }
}
// 适配器
public class LegacyPrinterAdapter : IPrinter {
private readonly LegacyPrinter _legacyPrinter;
public LegacyPrinterAdapter(LegacyPrinter legacyPrinter) {
_legacyPrinter = legacyPrinter;
}
public void Print(string document) {
_legacyPrinter.PrintDocument(document);
}
}2. 类适配器模式（Class Adapter Pattern）
- 实现方式：通过“继承”同时实现目标接口与被适配类。
- 优势：适用于支持多继承的语言或场景，对性能有更高要求时可考虑。
- 限制：C#只支持接口多继承，不支持类多继承，因此使用较少。
实战案例：多云存储统一操作
需求背景
你的.NET应用需支持三大云厂商存储SDK（Amazon S3、Azure Blob、Google Cloud），但API大相径庭。理想方案是对业务代码屏蔽底层差异，切换/新增云服务时无需动主代码库。
步骤详解
Step 1️⃣ 定义统一接口
public interface ICloudStorage {
Task UploadFileAsync(string path, Stream data);
Task<Stream> DownloadFileAsync(string path);
Task DeleteFileAsync(string path);
}Step 2️⃣ 各云厂商实现自己的Adapter
- S3StorageAdapter实现ICloudStorage，内部调用Amazon S3 SDK。
- AzureBlobStorageAdapter实现ICloudStorage，内部调用Azure Blob SDK。
- GoogleCloudStorageAdapter实现ICloudStorage，内部调用Google Cloud SDK。
Step 3️⃣ 注入适配器
通过依赖注入(DI)，按配置选择所需Adapter，实现灵活切换。
Step 4️⃣ 客户端透明使用
业务代码只依赖ICloudStorage，无感知具体云厂商，扩展和维护都很优雅！
何时该用/不该用适配器模式？
推荐使用场景
- 集成遗留系统（如SOAP与REST桥接）
- 标准化多个异构实现（如多日志、数据库或存储系统）
- 跨协议通信（gRPC ↔ REST等）
- 隔离第三方库或SDK
- 方便切换底层实现
不推荐场景
- 原本接口已兼容，无需中间层
- 能直接修改被适配对象时，建议直接改代码
- 简单转换逻辑，用工具方法更简单
- 对性能极致敏感场景（多一层调用有损耗）
- 小型项目或简单任务，避免过度抽象
总结 & 行动呼吁
一句话总结：适配器模式是.NET开发者应掌握的必备工具之一，让系统集成更加灵活、优雅且可维护。面对多变的外部依赖和遗留系统，它能助你一臂之力！💪
你怎么看？
你在实际项目中遇到过哪些需要用到Adapter模式的场景？有没有踩过坑？欢迎在评论区留言交流👇
如果觉得本文对你有帮助，别忘了分享给你的.NET小伙伴或者点个赞👍！