本文讲解如何避免通过继承链调用其他子类方法，转而采用依赖注入与接口抽象的方式，实现高内聚、低耦合的服务协作，提升代码可测试性与可维护性。
本文讲解如何避免通过继承链调用其他子类方法，转而采用依赖注入与接口抽象的方式，实现高内聚、低耦合的服务协作，提升代码可测试性与可维护性。
在 PHP 面向对象开发中，常见误区是试图让 Checkout 类继承 Base，再让 Email 类也继承 Base，最后期望 Checkout 能直接调用 Email 的方法（如 $this->sendEmail()）。但这种设计违背了单一职责原则，也隐含了不合理的继承耦合——Checkout 并不是一种特殊的 Email，也不应因“同属 Base”就获得访问权限。真正需要的，是清晰的协作契约与可控的依赖关系。
✅ 推荐方案：依赖注入 + 接口抽象
将邮件发送能力定义为一个独立服务，并通过接口明确其行为契约，再将其作为依赖注入到需要它的类中：
// 定义通信能力的抽象接口
interface MessengerInterface
{
public function send(string $message): bool;
}
// 具体实现：邮件发送器
class Mailer implements MessengerInterface
{
public function send(string $message): bool
{
// 实际邮件发送逻辑（如使用 PHPMailer 或 SMTP）
echo "Sending email: {$message}\n";
return true;
}
}
// 业务类不再继承通用基类，而是专注自身职责
class Checkout
{
public function __construct(
private MessengerInterface $messenger
) {
// 依赖由外部注入，无需关心具体实现
}
public function onCheckout(string $orderReference): void
{
$this->messenger->send("Your order {$orderReference} has been processed.");
}
}✅ 使用示例（无框架手动注入）
$mailer = new Mailer();
$checkout = new Checkout($mailer);
$checkout->onCheckout('ORD-2024-789');
// 输出：Sending email: Your order ORD-2024-789 has been processed.⚠️ 关键注意事项
- 拒绝“上帝基类”：避免创建泛化的 Base 类来承载所有功能，这会导致子类被迫继承无关职责，增加测试和重构成本。
- 接口优先，而非实现：Checkout 依赖 MessengerInterface，而非 Mailer。未来可轻松切换为 SmsMessenger 或 SlackMessenger，无需修改业务逻辑。
- 构造器注入优于 setter 或全局访问：确保依赖在对象创建时即完整、不可变，提升可预测性与线程安全性（在 CLI/Web 环境中均适用）。
- 避免循环依赖：若 Mailer 又需要 Checkout 的能力，说明职责划分失当，应回归领域建模，拆分更细粒度的服务或引入事件机制。
? 总结
子类之间“需要调用彼此方法”，本质是职责边界模糊或协作机制缺失的表现。PHP 中最健壮、可扩展的解法不是延长继承链，而是：
- 提炼稳定契约 → 定义接口；
- 将能力封装为独立服务 → 实现接口；
- 通过构造器注入依赖 → 显式声明协作关系。
这种方式天然支持单元测试（可注入 Mock 对象）、符合 SOLID 原则，并为后续集成 DI 容器（如 Symfony DI、PHP-DI）打下坚实基础。
立即学习“PHP免费学习笔记（深入）”；
