适配器模式解决已有类接口与新需求不匹配的调用障碍，如参数名、顺序、语义差异；它不处理协议级或网络层兼容，而是通过继承目标接口并组合被适配对象实现翻译桥接，推荐使用对象适配器以避免MRO冲突、提升灵活性和可测试性。
适配器模式解决的是什么兼容问题
它不解决「协议级」或「网络层」兼容，而是处理已有类的接口与当前需求不匹配时的调用障碍。比如你有一个 LegacyPaymentProcessor 类，只提供 make_payment(amount, account_id) 方法，但新业务要求统一调用 pay(amount, user_id) —— 参数名、顺序、语义都不同，这时直接继承或修改原类往往不可行（可能无源码、有副作用、违反开闭原则），适配器就是中间翻译层。
如何写一个最小可用的类适配器
核心是让适配器「继承目标接口」并「持有被适配对象」，再在方法中做参数映射和逻辑桥接：
class NewPaymentInterface:
def pay(self, amount: float, user_id: str) -> bool:
raise NotImplementedError
<p>class LegacyPaymentProcessor:
def make_payment(self, amount: float, account_id: str) -> bool:
print(f"Charging {amount} to account {account_id}")
return True</p><p>class LegacyToNewAdapter(NewPaymentInterface):
def <strong>init</strong>(self, legacy: LegacyPaymentProcessor):
self._legacy = legacy</p><pre class="brush:php;toolbar:false;">def pay(self, amount: float, user_id: str) -> bool:
# 关键：把 user_id 映射为 account_id（可能查表、加前缀等）
return self._legacy.make_payment(amount, f"ACC_{user_id}")
- 适配器必须实现目标接口的所有方法，哪怕只是抛
NotImplementedError占位 - 不要在
__init__里做耗时操作（如初始化连接），避免构造失败导致整个流程中断 - 如果
LegacyPaymentProcessor本身有状态（比如 session ID），确保适配器不意外重置它
对象适配器 vs 类适配器：选哪个更安全
Python 中「类适配器」靠多继承（继承目标接口 + 被适配类），看似简洁但容易引发 MRO 冲突，尤其当被适配类已有 __init__ 或覆盖了目标接口同名方法时；「对象适配器」更推荐，因为它只依赖组合，隔离性好，且能适配任何对象（包括内置类型、第三方库实例）：
立即学习“Python免费学习笔记（深入）”；
# 对象适配器：安全、灵活、可测试
class PaymentAdapter:
def __init__(self, processor):
self._processor = processor # 任意有 make_payment 方法的对象
<pre class="brush:php;toolbar:false;">def pay(self, amount, user_id):
return self._processor.make_payment(amount, self._to_account_id(user_id))
def _to_account_id(self, user_id):
return user_id.replace("U-", "ACC-") # 可单独单元测试
- 对象适配器支持运行时替换被适配对象（比如切 mock 或降级实例）
- 若被适配对象方法签名动态变化（如某些 ORM 模型），对象适配器可通过
hasattr或getattr做兜底，类适配器会直接报AttributeError - 避免在适配器里补全缺失功能（比如给没加密的旧支付加 AES），那是装饰器或策略模式的事
常见踩坑：适配器成了隐藏的性能瓶颈
适配器本身不该引入显著开销，但实践中容易忽略两点：
- 每次
pay()都新建一次 HTTP session 或数据库连接 —— 应把连接池/客户端实例传入，而非在方法内初始化 - 在
_to_account_id()这类映射函数里调用远程服务（如查用户中心）—— 这会让原本同步的支付接口变成强依赖，超时风险陡增 - 对返回值不做类型校验，比如旧接口返回字符串
"success"，新接口契约要求布尔值，结果下游逻辑因if response:误判而跳过错误处理
真正难的不是写适配器，而是厘清哪些差异该由它消化，哪些必须推动上游改——比如字段语义冲突（user_id 实际存的是手机号）、时间格式混用（秒级 vs 毫秒级 timestamp），这类问题光靠适配器掩盖，迟早会在日志、对账或审计环节暴露。
