陆拾贰號1. 适配器模式概述
适配器模式（Adapter Pattern）是一种结构型设计模式，它允许不兼容的接口之间进行协作。就像现实生活中电源插头转换器一样，适配器模式在两个不兼容的接口之间充当"桥梁"的角色。
在实际开发中，我们经常会遇到这样的场景：系统需要使用某个类，但这个类的接口与系统要求的接口不匹配。这时候，与其修改原有代码（可能影响其他依赖该类的模块），不如创建一个适配器来转换接口。
适配器模式主要分为两种实现方式：
- 类适配器：通过多重继承实现（在C#中需要通过接口模拟）
- 对象适配器：通过组合方式实现
提示：在C#等不支持多重继承的语言中，通常推荐使用对象适配器方式，它更灵活且符合组合优于继承的原则。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 适配器模式的核心结构
2.1 角色定义
适配器模式包含三个核心角色：
- 目标接口（Target）：客户端期望使用的接口
- 适配者（Adaptee）：需要被适配的现有接口
- 适配器（Adapter）：将Adaptee接口转换为Target接口的中间件
2.2 UML类图解析
code复制[客户端] --> [Target接口]
[Target接口] <|-- [Adapter]
[Adapter] --> [Adaptee]
这个结构清晰地展示了：
- 客户端只与Target接口交互
- Adapter实现了Target接口
- Adapter内部持有Adaptee实例并调用其方法
3. 适配器模式实现详解
3.1 对象适配器实现
这是最常用的适配器实现方式，我们通过一个实际案例来说明：
csharp复制// 目标接口
public interface ILogger
{
void Log(string message);
void Error(string message);
void Warn(string message);
}
// 需要适配的第三方日志类
public class ThirdPartyLogger
{
public void LogMessage(string message) { /*...*/ }
public void LogError(string error) { /*...*/ }
public void LogWarning(string warning) { /*...*/ }
}
// 适配器实现
public class LoggerAdapter : ILogger
{
private readonly ThirdPartyLogger _adaptee;
public LoggerAdapter(ThirdPartyLogger adaptee)
{
_adaptee = adaptee;
}
public void Log(string message)
{
_adaptee.LogMessage(message);
}
public void Error(string message)
{
_adaptee.LogError(message);
}
public void Warn(string message)
{
_adaptee.LogWarning(message);
}
}
使用示例：
csharp复制// 客户端代码
ILogger logger = new LoggerAdapter(new ThirdPartyLogger());
logger.Log("系统启动"); // 实际调用ThirdPartyLogger的LogMessage方法
3.2 类适配器实现
在支持多重继承的语言中，类适配器可以通过继承目标类和适配者类来实现。在C#中，我们可以通过接口继承来模拟：
csharp复制// 目标接口
public interface ILogger
{
void Log(string message);
// ...
}
// 适配者接口
public interface IThirdPartyLogger
{
void LogMessage(string message);
// ...
}
// 适配器实现
public class LoggerAdapter : ILogger, IThirdPartyLogger
{
// 实现ILogger接口
public void Log(string message)
{
// 调用自身的适配者方法
this.LogMessage(message);
}
// 实现IThirdPartyLogger接口
public void LogMessage(string message) { /*...*/ }
// ...
}
注意：类适配器方式在C#中不够直观，且灵活性较差，通常建议优先使用对象适配器。
4. 适配器模式的应用场景
4.1 典型使用场景
适配器模式特别适用于以下情况：
- 集成第三方库：当需要使用的第三方组件接口与系统不兼容时
- 接口升级兼容：新版本接口需要兼容旧版本代码时
- 统一多个类的接口：系统中存在多个功能类似但接口不同的类，需要统一调用方式
- 遗留系统集成：与老旧系统对接时，避免直接修改原有代码
4.2 实际案例：支付网关集成
假设我们正在开发一个电商系统，需要集成多个支付网关（支付宝、微信支付、银联等），每个支付网关的SDK接口都不相同。这时可以使用适配器模式：
csharp复制// 统一支付接口
public interface IPaymentService
{
bool Pay(decimal amount);
bool Refund(decimal amount);
}
// 支付宝适配器
public class AlipayAdapter : IPaymentService
{
private readonly AlipaySDK _alipay;
public AlipayAdapter(AlipaySDK alipay)
{
_alipay = alipay;
}
public bool Pay(decimal amount)
{
return _alipay.SendPayment(amount.ToString("0.00"));
}
public bool Refund(decimal amount)
{
return _alipay.RequestRefund(amount.ToString("0.00"));
}
}
// 微信支付适配器
public class WechatPayAdapter : IPaymentService
{
private readonly WechatPayService _wechatPay;
public WechatPayAdapter(WechatPayService wechatPay)
{
_wechatPay = wechatPay;
}
public bool Pay(decimal amount)
{
return _wechatPay.MakePayment((int)(amount * 100));
}
public bool Refund(decimal amount)
{
return _wechatPay.DoRefund((int)(amount * 100));
}
}
这样，业务代码只需要与IPaymentService接口交互，无需关心底层支付SDK的具体实现。
5. 适配器模式的优缺点分析
5.1 优势
- 解耦客户端与适配者：客户端只依赖目标接口，不直接依赖具体实现
- 开闭原则：可以在不修改现有代码的情况下引入新的适配器
- 单一职责原则：将接口转换逻辑从业务逻辑中分离出来
- 复用性：可以让多个不兼容的类一起工作
5.2 局限性
- 过度使用会增加复杂性：如果系统中适配器过多，会使得代码结构变得复杂
- 性能开销：额外的间接调用会带来轻微的性能损耗（通常可以忽略不计）
- 可能掩盖设计问题：有时接口不匹配可能是设计缺陷的信号，使用适配器可能只是临时解决方案
6. 适配器模式的最佳实践
6.1 实现技巧
- 保持适配器简单：适配器只应包含必要的转换逻辑，不应包含业务逻辑
- 命名规范：使用"Adapter"后缀明确标识适配器类，如"AlipayAdapter"
- 接口设计：目标接口应尽可能通用，避免与特定适配者的实现细节耦合
- 依赖注入：通过DI容器管理适配器生命周期，提高可测试性
6.2 常见问题与解决方案
问题1：适配器需要转换大量方法怎么办？
解决方案：
- 考虑是否可以将目标接口拆分为更小的接口（接口隔离原则）
- 如果确实需要大量转换，可以创建中间抽象层
问题2：如何处理适配者接口的变化？
解决方案：
- 为适配器创建抽象基类或接口
- 使用策略模式动态选择适配策略
问题3：如何测试适配器？
推荐做法：
csharp复制[Test]
public void Adapter_Should_Convert_Correctly()
{
// Arrange
var adaptee = new Mock<IAdaptee>();
adaptee.Setup(a => a.SpecificRequest()).Returns("adapted");
var adapter = new Adapter(adaptee.Object);
// Act
var result = adapter.Request();
// Assert
Assert.AreEqual("adapted", result);
}
7. 适配器模式与其他模式的关系
7.1 与装饰器模式对比
- 适配器：转换接口，使不兼容的接口能够协作
- 装饰器：增强接口，在不改变接口的前提下添加功能
7.2 与外观模式对比
- 适配器：主要解决接口不兼容问题，通常是一对一的映射
- 外观：为复杂子系统提供简化接口，通常是一对多的关系
7.3 与桥接模式对比
- 适配器：通常在系统设计完成后使用，解决已有组件的不兼容问题
- 桥接：在系统设计初期使用，将抽象与实现分离以便独立变化
8. 实战经验分享
在实际项目中使用适配器模式时，我总结了以下几点经验：
-
尽早引入适配器：当发现需要频繁修改代码来适应第三方接口时，就应该考虑使用适配器模式
-
适配器+工厂模式：结合工厂模式可以动态创建合适的适配器，提高灵活性
csharp复制public class PaymentAdapterFactory
{
public IPaymentService Create(PaymentType type)
{
switch(type)
{
case PaymentType.Alipay:
return new AlipayAdapter(new AlipaySDK());
case PaymentType.Wechat:
return new WechatPayAdapter(new WechatPayService());
default:
throw new NotSupportedException();
}
}
}
-
日志记录：在适配器中添加适当的日志记录，便于调试接口转换问题
-
性能考虑：对于高频调用的适配器，可以考虑缓存转换结果或使用更高效的转换方式
-
文档注释：为适配器添加详细注释，说明原始接口和目标接口的对应关系
适配器模式是日常开发中非常实用的设计模式，特别是在集成第三方组件和系统时。掌握好这个模式可以让你在保持系统架构整洁的同时，灵活地集成各种外部服务。