PHP观察者模式代码实现解析

本文深入解析了PHP中观察者模式的现代实现方式，重点指出自PHP 8.0起SPL内置的SplSubject/SplObserver接口已被废弃并移除，开发者必须转向自定义SubjectInterface和ObserverInterface以确保代码兼容性与可维护性；文章不仅提供了精简可靠的接口定义和手写实现示例（如User被观察者与EmailNotifier、LogWriter观察者），还详解了关键设计细节——包括观察者注册去重、异常隔离处理、避免循环通知，并推荐通过事件对象（EventInterface）优雅扩展上下文传递能力；同时澄清了Laravel/Symfony等框架事件系统的本质差异，强调其作为高级事件总线与经典观察者模式在抽象层级、语义清晰度和教学价值上的根本区别，最后点明该模式本身不提供异步或事务保障，需开发者根据实际场景主动增强——真正想掌握设计模式精髓，就得从亲手定义契约、控制通知流开始。

Observer 接口和 SplSubject/SplObserver 是什么关系

PHP 标准库（SPL）自带了 SplSubject 和 SplObserver 接口，但它们在 PHP 8.0 起已被标记为废弃（Deprecated），PHP 8.1+ 完全移除。直接依赖这两个接口的代码会在新版 PHP 报 Deprecated: Class SplSubject is deprecated 警告甚至致命错误。

这意味着：别再用 SplSubject 做基类，也别在类型提示里写 SplObserver。现代 PHP 观察者模式必须手写接口或基于 PSR/自定义契约实现。

• PHP 7.4 及以下可临时用，但不推荐新项目启用
• PHP 8.0+ 必须替换为自定义 ObserverInterface 和 SubjectInterface
• 框架如 Laravel 的事件系统（EventDispatcher）本质是观察者变体，但不是标准实现，不能直接当“观察者模式教学案例”用

手动实现 Subject + Observer 的最小可行结构

核心就三件事：被观察者（Subject）维护观察者列表、提供注册/注销方法、触发通知；观察者（Observer）实现统一更新方法。关键在于解耦——Subject 不知道 Observer 具体做什么，只调用其 update()。

interface SubjectInterface
{
    public function attach(ObserverInterface $observer): void;
    public function detach(ObserverInterface $observer): void;
    public function notify(): void;
}

interface ObserverInterface
{
    public function update(SubjectInterface $subject): void;
}

class User implements SubjectInterface
{
    private array $observers = [];
    private string $status = '';

    public function attach(ObserverInterface $observer): void
    {
        $this->observers[] = $observer;
    }

    public function detach(ObserverInterface $observer): void
    {
        $key = array_search($observer, $this->observers, true);
        if ($key !== false) {
            unset($this->observers[$key]);
        }
    }

    public function notify(): void
    {
        foreach ($this->observers as $observer) {
            $observer->update($this);
        }
    }

    public function setStatus(string $status): void
    {
        $this->status = $status;
        $this->notify();
    }

    public function getStatus(): string
    {
        return $this->status;
    }
}

class EmailNotifier implements ObserverInterface
{
    public function update(SubjectInterface $subject): void
    {
        if ($subject instanceof User && $subject->getStatus() === 'active') {
            echo "Send welcome email\n";
        }
    }
}

class LogWriter implements ObserverInterface
{
    public function update(SubjectInterface $subject): void
    {
        echo "Log: user status changed to " . $subject->getStatus() . "\n";
    }
}

注意点：

• attach() 和 detach() 必须支持同一实例多次注册（需去重）或明确文档说明行为
• notify() 中若某个 update() 抛异常，默认应继续执行其余观察者（避免一个失败阻断全部）
• 不要在 update() 里反向调用 Subject 的修改方法，容易引发循环通知

如何传递更丰富的上下文数据

原生 update(SubjectInterface $subject) 只传入自身，但实际中常需额外参数（如旧值、事件名、payload）。常见做法有三种：

• 把数据挂到 Subject 属性上（如 $this->lastChange = ['from' => 'pending', 'to' => 'active']），观察者从 $subject 里取——简单但污染 Subject
• 扩展 update() 签名，加可选参数：但会破坏接口一致性，所有 Observer 都得实现带默认值的签名
• 引入事件对象（推荐）：定义 EventInterface，让 notify(EventInterface $event) 替代无参 notify()

示例改造片段：

interface EventInterface
{
    public function getName(): string;
    public function getData(): array;
}

class StatusChangedEvent implements EventInterface
{
    public function __construct(
        private string $oldStatus,
        private string $newStatus
    ) {}

    public function getName(): string
    {
        return 'user.status_changed';
    }

    public function getData(): array
    {
        return ['old' => $this->oldStatus, 'new' => $this->newStatus];
    }
}

// 修改 SubjectInterface：
interface SubjectInterface
{
    public function attach(ObserverInterface $observer): void;
    public function detach(ObserverInterface $observer): void;
    public function notify(EventInterface $event): void;
}

// Observer update() 变成：
interface ObserverInterface
{
    public function update(SubjectInterface $subject, EventInterface $event): void;
}

为什么不用 Laravel Event 或 Symfony EventDispatcher

它们是生产级事件总线，不是观察者模式的教学实现。关键区别：

• EventDispatcher 支持事件名称字符串匹配、优先级、监听器懒加载、异常中断策略——远超观察者模式的“一对多通知”原始语义
• 注册监听器用 addListener('user.created', [...])，不强制实现统一接口，灵活性高但抽象层级不同
• 调试时你看到的是 “dispatch ‘user.created’”，而不是 “User::notify()”——语义丢失，不利于理解设计模式本意

真要学观察者模式，就该从接口定义开始，亲手控制通知时机和数据流向。框架封装得太深，反而掩盖了“谁通知谁”“怎么解耦”的关键逻辑。

最易被忽略的一点：观察者模式本身不解决异步、队列、事务一致性等问题。如果 notify() 里调用了发邮件、写日志等 I/O 操作，它默认是同步阻塞的——这在 Web 请求中可能拖慢响应，需要你自己决定是否丢进队列或协程处理。

今天关于《PHP观察者模式代码实现解析》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！