本文讲解如何在 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 工程实践的基石。
