PHP架构中观察者模式怎么实现_代码示例【详解】

SplSubject/SplObserver 是 PHP SPL 提供的观察者模式接口,但自 PHP 8.0 起废弃、8.1+ 移除,现代 PHP 应使用自定义 SubjectInterface 和 ObserverInterface 实现解耦通知机制。

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

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

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

  • PHP 7.4 及以下可临时用,但不推荐新项目启用
  • PHP 8.0+ 必须替换为自定义 ObserverInterfaceSubjectInterface
  • 框架如 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 请求中可能拖慢响应,需要你自己决定是否丢进队列或协程处理。