PHP项目为何用适配器模式？低成本对接旧系统解析

PHP项目采用适配器模式并非追求设计模式的“高大上”，而是直面现实困境的务实选择——当无法修改被封装在.phar中、无源码可查却仍在生产环境运行的旧类（如LegacyLogger），又必须严格遵循PSR-3等新接口标准时，适配器是唯一能当天上线、零侵入旧系统、不妥协新规范的解法；它通过组合而非继承，在构造函数中显式持有旧实例，仅做最轻量的参数转换与方法转发，拒绝业务逻辑、新依赖或副作用，真正扮演好“翻译官”角色，让新老系统在不互相改造的前提下即刻协同运转。

PHP项目需要适配器模式，不是因为“设计模式很高级”，而是因为现实里你根本改不了旧代码——比如一个被封装在.phar里、没有源码、但还在生产环境跑着的LegacyLogger类，它只接受log($level, $msg, $context)，而新系统统一要求PSR-3 LoggerInterface::log($level, $message, array $context)。这时候，硬改调用方或重写旧类都不现实，适配器是唯一能当天上线的解法。

旧类不能动，新接口又必须满足：适配器是唯一出口

你遇到的不是“要不要用设计模式”的问题，是“不加一层中间转发就编译不过”的硬约束。常见触发场景包括：

• 第三方 SDK 升级后方法签名变了（比如sendEmail($to, $subject, $body) → send(Message $msg)）
• 框架升级强制依赖新标准（如从自定义日志类切到LoggerInterface）
• 并购项目里对方系统用的是完全不同的参数顺序/类型/返回值结构

关键点在于：适配器不解决“谁对谁错”，只解决“怎么让它们现在就能一起跑”。它不修改旧类，也不要求新系统妥协，只做最小转换。

适配器类必须显式持有被适配对象，不能靠“实现同一接口”蒙混过关

新手最常踩的坑是写完class LegacyLoggerAdapter implements LoggerInterface就以为完事了，结果运行时报Call to undefined method LegacyLogger::log()——因为旧类根本没log()方法，只有write()或output()。

正确做法是：

• 构造函数必须接收旧对象实例：public function __construct(LegacyLogger $legacy)
• 在log()里手动调用$this->legacy->write(...)，并完成参数重组（比如把$context数组拆成单独参数）
• 不要试图在适配器里补全旧类缺失的功能（如自动加时间戳），那已超出适配边界，属于业务逻辑迁移

示例片段：

class LegacyLoggerAdapter implements LoggerInterface
{
    private $legacy;

    public function __construct(LegacyLogger $legacy)
    {
        $this->legacy = $legacy;
    }

    public function log($level, $message, array $context = [])
    {
        // 旧类不支持数组 context，只接受字符串
        $flatContext = json_encode($context);
        $this->legacy->write($level, $message . ' | ' . $flatContext);
    }
}

自动加载和类型安全必须手工对齐，否则注入就失败

即使代码逻辑写对了，如果 Composer 的autoload没配好，或者类型声明不严格，DI 容器会直接拒绝实例化适配器。典型问题有：

• LegacyLogger类不在 PSR-4 命名空间下，require_once路径写错导致Class not found
• 适配器构造函数声明LegacyLogger $legacy，但传入的是LegacyLoggerV2，PHP 8+ 会报TypeError
• 旧类是final，但你在适配器里试图extends它（错误思路！适配器应compose而非inherit）

检查清单：

• 确认composer.json中autoload.files包含旧类文件路径
• 用php -l验证语法，再用phpstan扫一遍类型兼容性
• 在测试中用assertInstanceOf(LoggerInterface::class, $adapter)确保接口契约成立

别把适配器写成胶水层：薄、快、无副作用

适配器一旦开始处理业务逻辑（比如在processPayment()里加风控校验）、或引入新依赖（如在日志适配器里偷偷连 Redis）、或做异步调度，它就不再是适配器，而是新模块——维护成本立刻翻倍，且违背“解耦”初衷。

判断是否过界，就看这一行代码：

• ✅ 只出现$this->legacy->xxx(...)、return $result、throw new AdapterException(...)
• ❌ 出现new SomeService()、file_get_contents()、if ($level === 'error') { sendAlert() }

真正难的从来不是写适配器，而是守住那条线：它只是翻译官，不是决策者。

理论要掌握，实操不能落！以上关于《PHP项目为何用适配器模式？低成本对接旧系统解析》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！