本文讲解如何在 php 中避免通过多层继承耦合业务类（如 checkout 与 email），转而采用依赖注入（di）和接口抽象实现松耦合、可测试、易维护的代码结构。
本文讲解如何在 php 中避免通过多层继承耦合业务类（如 checkout 与 email），转而采用依赖注入（di）和接口抽象实现松耦合、可测试、易维护的代码结构。
在面向对象设计中，当 Checkout 类需要调用邮件发送功能时，不应让其继承 Email 类，也不应让两者共同继承一个空泛的 Base 类——这种做法违背了单一职责原则，且导致强耦合、难以复用和单元测试。正确的实践是：将“发送消息”这一能力抽象为服务（Service），并通过依赖注入显式提供给需要它的类。
✅ 推荐方案：接口 + 构造器注入
首先定义清晰的契约接口，明确服务行为：
// src/Contracts/MessengerInterface.php interface MessengerInterface {public function send(string $message): bool; }接着实现具体服务（如邮件发送）：
// src/Services/Mailer.php class Mailer implements MessengerInterface {public function send(string $message): bool {// 实际邮件发送逻辑（例如使用 PHPMailer 或 Symfony Mailer）echo "Sending email: {$message}n"; return true; } }然后在业务类中 通过构造函数声明依赖，而非继承或手动实例化：
立即学习“PHP 免费学习笔记（深入）”；
// src/Services/Checkout.php class Checkout {public function __construct( private MessengerInterface $messenger) {} public function onCheckout(string $orderRef): void {$this->messenger->send("Your order {$orderRef} has been processed."); } }使用示例（无框架场景）：
// index.php require_once 'src/Contracts/MessengerInterface.php'; require_once 'src/Services/Mailer.php'; require_once 'src/Services/Checkout.php'; $mailer = new Mailer(); $checkout = new Checkout($mailer); $checkout->onCheckout('ORD-2024-001'); // 输出：Sending email: Your order ORD-2024-001 has been processed.⚠️ 关键注意事项
- 拒绝“上帝基类”：Base 类若不承载共用逻辑（如日志、认证、数据库连接），仅作继承占位，则属于反模式。它掩盖了真实依赖关系，增加理解与维护成本。
- 优先组合，而非继承：Checkout has a Messenger，而非 is a Email —— 这更符合现实语义，也便于未来切换实现（如改用短信 SmsMessenger 或站内信 NotificationService）。
- 接口即协议：MessengerInterface 保证了 Checkout 不依赖具体实现，仅依赖行为契约，为 Mock 测试、AOP 扩展等留出空间。
- 框架集成友好：主流 DI 容器（如 Laravel IoC、Symfony DI、PHP-DI）可自动解析 MessengerInterface → Mailer 映射，无需手动传参。
? 总结
解决“子类需调用另一子类方法”的问题，本质是识别并解耦隐式依赖。与其构建脆弱的继承链（Base → Checkout, Base → Email），不如用 接口定义能力、用依赖注入交付能力。这种方式提升了代码内聚性、降低了耦合度，并天然支持可插拔架构与自动化测试——这才是现代 PHP 工程实践的基石。
