PHP怎样实现中介者设计模式_PHP实现中介者设计模式方法【架构】-php教程-PHP中文网

PHP中绝大多数场景不需要手动实现中介者模式，因其Web请求生命周期短、协作关系扁平，强行使用反而增加复杂度；仅在多组件联动、WebSocket状态协调或CLI子命令事件共享等高耦合场景才需显式引入Mediator类。

php怎样实现中介者设计模式_php实现中介者设计模式方法【架构】

中介者模式在 PHP 里到底该不该手写

直接说结论：PHP 中绝大多数场景不需要手动实现中介者模式。它不是语言级设施，而是为了解耦高度耦合的同事对象（Colleague）而存在的结构型模式；但在 PHP 的典型 Web 请求生命周期中，对象存活时间短、协作关系扁平（比如 Controller 调用 Service，Service 调用 Repository），根本达不到需要“中介者统一协调多个交互方”的复杂度。强行套用反而让代码更难读、更难测。

什么情况下真得用 `Mediator` 类

只有当出现以下任一情况时，才值得引入一个显式的 Mediator 类：

多个表单组件（如 DatePicker、TimeSelector、LocationAutocomplete）需要联动更新，且它们彼此不能直接引用对方（避免循环依赖或破坏封装）
WebSocket 长连接服务中，多个客户端实例需通过中心逻辑协调状态（例如聊天室中 A 发言触发 B 的提示音 + C 的未读计数 + D 的消息存档）
命令行工具里多个子命令（ImportCommand、ValidateCommand、SyncCommand）需共享上下文并响应彼此事件，但又不能硬编码调用链

这时 Mediator 不是“为了设计模式而存在”，而是把原本散落在各处的 if-else 协调逻辑收拢到一处，降低变更成本。

`Mediator` 接口和同事类怎么写才不翻车

常见错误是让同事类（Colleague）持有 Mediator 实例并主动调用其方法，结果变成“同事控制中介者”，违背了中介者“隔离同事”的本意。正确做法是同事只通知事件，中介者决定如何响应：

// 同事基类：只发信号，不关心谁处理
abstract class Colleague
{
    protected Mediator $mediator;
    public function setMediator(Mediator $mediator): void
    {
        $this->mediator = $mediator;
    }
    // 关键：用事件名 + 数据，而非调用具体方法
    protected function notify(string $event, array $data = []): void
    {
        $this->mediator->handle($event, $data, $this);
    }
}

// 中介者接口：明确事件契约
interface Mediator
{
    public function handle(string $event, array $data, Colleague $sender): void;
}

// 具体中介者：所有协调逻辑集中在此
class ChatRoomMediator implements Mediator
{
    private array $colleagues = [];

    public function register(Colleague $colleague): void
    {
        $this->colleagues[] = $colleague;
        $colleague->setMediator($this);
    }

    public function handle(string $event, array $data, Colleague $sender): void
    {
        match($event) {
            'message_sent' => $this->broadcastMessage($data, $sender),
            'user_joined' => $this->notifyAll('user_status_changed', [...]),
            default => throw new \LogicException("Unhandled event: {$event}"),
        };
    }
}

注意点：

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

同事类必须用 setMediator() 注入，不能在构造时强制依赖——否则单元测试无法 mock
handle() 方法签名里保留 $sender，否则无法判断“谁触发的”，联动逻辑会失效
不要在 Mediator 里 new 具体同事类，否则破坏解耦；同事应由上层容器创建后注册进来

Laravel 或 Symfony 项目里别自己造轮子

框架本身已提供更轻量、更符合 PHP 习惯的替代方案：

Laravel 的 Event + Listener 机制就是中介者的函数式实现：OrderPlaced 事件触发 SendEmailListener、UpdateInventoryListener、LogActivityListener，完全解耦
Symfony 的 EventDispatcher 同理，且支持优先级、停止传播等控制能力
连 Laravel 的 Observers（如 UserObserver）本质也是中介者变体：模型状态变化 → 触发外部响应