适配器模式是“套一层壳”而非修改原接口，因AudioPlayer等已上线类无法直接改动；它通过实现目标接口并持有适配者实例来透明转发调用，真正干净的适配器代码应很薄。
适配器模式不是“改接口”，而是“套一层壳”让调用方感觉不到底层不兼容。
为什么不能直接改原有类的接口
现实里你根本没法动 AudioPlayer 或 Doc2007 这类已上线、被多处依赖的类：它可能来自第三方库、jar 包，或已被其他模块强耦合调用。强行改 playMp3() 方法签名，等于让所有调用方一起改代码——成本远高于加个适配器。
- 改原类 = 所有依赖方同步升级，风险高、周期长
- 加适配器 = 客户端只认
AdvancedAudioPlayer.play()，内部怎么转、转多少次，它完全不知道 - 适配器本身可测试、可替换、可日志埋点，不影响旧逻辑
适配器怎么做到“透明转换”
关键在客户端只依赖目标接口（如 Motor 或 IDoc2003），而适配器类（如 ElectricAdapter）同时满足两个条件：
- 实现目标接口（
implements Motor），所以能被客户端当Motor用 - 持有适配者实例（
private $emotor），把drive()调用转发给$emotor->electricDrive() - 转发时可做参数转换、格式封装、异常兜底——比如把
fileName+audioType拆解后喂给playMp3()
容易忽略的边界：适配器不是万能胶水
一旦发现要频繁在适配器里写大量 if-else 判断类型、做复杂数据转换、甚至补全缺失功能（比如 Doc2007 根本没有 print() 方法，硬在适配器里模拟），就该警觉了：
- 这已经不是接口适配，而是功能缝合——说明设计上存在断裂，该重构而不是硬适配
- 适配器里出现
convertVlcToMp3()这种耗时操作，会掩盖真实性能瓶颈 - 如果多个适配器都包装同一个
Adaptee，且逻辑高度重复，说明缺一个统一的转换层，而非单个适配器问题
真正干净的适配器，代码通常很薄：几行委托、一两个字段、零业务逻辑。厚，往往意味着问题不在接口，而在架构。
