架构设计模式观察者模式

在软件系统中，有些对象之间存在类似交通信号灯和汽车之间的关系，一个对象的状态或行为的变化将导致其他对象的状态或行为也发生改变，它们之间将产生联动，正所谓“触一而牵百发”。为了更好地描述对象之间存在的这种一对多（包括一对一）的联动，观察者模式应运而生，它定义了对象之间一种一对多的依赖关系，让一个对象的改变能够影响其他对象。

观察者模式是使用频率最高的设计模式之一，它用于建立一种对象与对象之间的依赖关系，一个对象发生改变时将自动通知其他对象，其他对象将相应作出反应。在观察者模式中，发生改变的对象称为观察目标，而被通知的对象称为观察者，一个观察目标可以对应多个观察者，而且这些观察者之间可以没有任何相互联系，可以根据需要增加和删除观察者，使得系统更易于扩展。

观察者模式定义如下：

观察者模式(Observer Pattern)：定义对象之间的一种一对多依赖关系，使得每当一个对象状态发生改变时，其相关依赖对象皆得到通知并被自动更新。观察者模式的别名包括发布 - 订阅（Publish/Subscribe）模式、模型 - 视图（Model/View）模式、源 - 监听器（Source/Listener）模式或从属者（Dependents）模式。观察者模式是一种对象行为型模式。

观察者模式结构中通常包括观察目标和观察者两个继承层次结构，其结构如图所示：

在观察者模式结构图中包含如下几个角色：

Subject（目标）：目标又称为主题，它是指被观察的对象。在目标中定义了一个观察者集合，一个观察目标可以接受任意数量的观察者来观察，它提供一系列方法来增加和删除观察者对象，同时它定义了通知方法 notify()。目标类可以是接口，也可以是抽象类或具体类。
ConcreteSubject（具体目标）：具体目标是目标类的子类，通常它包含有经常发生改变的数据，当它的状态发生改变时，向它的各个观察者发出通知；同时它还实现了在目标类中定义的抽象业务逻辑方法（如果有的话）。如果无须扩展目标类，则具体目标类可以省略。
Observer（观察者）：观察者将对观察目标的改变做出反应，观察者一般定义为接口，该接口声明了更新数据的方法 update()，因此又称为抽象观察者。
ConcreteObserver（具体观察者）：在具体观察者中维护一个指向具体目标对象的引用，它存储具体观察者的有关状态，这些状态需要和具体目标的状态保持一致；它实现了在抽象观察者 Observer 中定义的 update()方法。通常在实现时，可以调用具体目标类的 attach()方法将自己添加到目标类的集合中或通过 detach()方法将自己从目标类的集合中删除。

观察者模式描述了如何建立对象与对象之间的依赖关系，以及如何构造满足这种需求的系统。观察者模式包含观察目标和观察者两类对象，一个目标可以有任意数目的与之相依赖的观察者，一旦观察目标的状态发生改变，所有的观察者都将得到通知。作为对这个通知的响应，每个观察者都将监视观察目标的状态以使其状态与目标状态同步，这种交互也称为发布 - 订阅(Publish-Subscribe)。观察目标是通知的发布者，它发出通知时并不需要知道谁是它的观察者，可以有任意数目的观察者订阅它并接收通知。

下面通过示意代码来对该模式进行进一步分析。首先我们定义一个抽象目标 Subject，典型代码如下所示：

abstract class Subject
{
    /**
     * 定义一个观察者集合用于存储所有观察者对象
     * @var Observer[]
     */
    protected $observers = [];

    // 注册方法，用于向观察者集合中增加一个观察者
    public function attach(Observer $observer)
    {$this->observers[] = $observer;
    }

    // 注销方法，用于在观察者集合中删除一个观察者
    public function detach(Observer $observer)
    {unset($this->observers[array_search($observer, $this->observers)]);
    }

    // 声明抽象通知方法
    abstract public function notify();}

具体目标类 ConcreteSubject 是实现了抽象目标类 Subject 的一个具体子类，其典型代码如下所示：

class concreteSubject extends Subject
{
    // 实现通知方法
    public function notify()
    {foreach ($this->observers as $observer)
        {$observer->update();
        }
    }
}

抽象观察者角色一般定义为一个接口，通常只声明一个 update()方法，为不同观察者的更新（响应）行为定义相同的接口，这个方法在其子类中实现，不同的观察者具有不同的响应方法。抽象观察者 Observer 典型代码如下所示：

interface Observer
{
    // 声明响应方法
    public function update();}

在具体观察者 ConcreteObserver 中实现了 update()方法，其典型代码如下所示：

class ConcreteObserver implements Observer
{
    // 实现响应方法
    public function update()
    {}}

在有些更加复杂的情况下，具体观察者类 ConcreteObserver 的 update()方法在执行时需要使用到具体目标类 ConcreteSubject 中的状态（属性），因此在 ConcreteObserver 与 ConcreteSubject 之间有时候还存在关联或依赖关系，在 ConcreteObserver 中定义一个 ConcreteSubject 实例，通过该实例获取存储在 ConcreteSubject 中的状态。如果 ConcreteObserver 的 update()方法不需要使用到 ConcreteSubject 中的状态属性，则可以对观察者模式的标准结构进行简化，在具体观察者 ConcreteObserver 和具体目标 ConcreteSubject 之间无须维持对象引用。如果在具体层具有关联关系，系统的扩展性将受到一定的影响，增加新的具体目标类有时候需要修改原有观察者的代码，在一定程度上违反了“开闭原则”，但是如果原有观察者类无须关联新增的具体目标，则系统扩展性不受影响。

Sunny 软件公司欲开发一款多人联机对战游戏（类似魔兽世界、星际争霸等游戏），在该游戏中，多个玩家可以加入同一战队组成联盟，当战队中某一成员受到敌人攻击时将给所有其他盟友发送通知，盟友收到通知后将作出响应。

Sunny 软件公司开发人员需要提供一个设计方案来实现战队成员之间的联动。

Sunny 软件公司开发人员通过对系统功能需求进行分析，发现在该系统中战队成员之间的联动过程可以简单描述如下：

联盟成员受到攻击 –> 发送通知给盟友 –> 盟友作出响应

如果按照上述思路来设计系统，由于联盟成员在受到攻击时需要通知他的每一个盟友，因此每个联盟成员都需要持有其他所有盟友的信息，这将导致系统开销较大，因此 Sunny 公司开发人员决定引入一个新的角色——“战队控制中心”——来负责维护和管理每个战队所有成员的信息。当一个联盟成员受到攻击时，将向相应的战队控制中心发送求助信息，战队控制中心再逐一通知每个盟友，盟友再作出响应。

为了实现对象之间的联动，Sunny 软件公司开发人员决定使用观察者模式来进行多人联机对战游戏的设计，其基本结构如图所示：

AllyControlCenter 充当目标类，ConcreteAllyControlCenter 充当具体目标类，Observer 充当抽象观察者，Player 充当具体观察者。完整代码如下所示：

<?php

// 抽象观察类
interface Observer
{public function getName(): string;

    public function setName(string $name): void;

    // 声明支援盟友方法
    public function help(): void;

    // 声明遭受攻击方法
    public function beAttacked(AllyControlCenter $acc): void;
}

// 战队成员类：具体观察者类
class Player implements Observer
{
    /**
     * @var string
     */
    private $name;

    public function __construct(string $name)
    {$this->name = $name;}

    public function setName(string $name): void
    {$this->name = $name;}

    public function getName(): string
    {return $this->name;}

    // 支援盟友方法的实现
    public function help(): void
    {echo $this->name . 'is on the way to save you';}

    // 遭受攻击方法的实现，当遭受攻击时将调用战队控制中心类的通知方法 notifyObserver()来通知盟友
    public function beAttacked(AllyControlCenter $acc): void
    {
        echo $this->name . 'is under attacked';
        $acc->notifyObserver($this->name);
    }
}

// 战队控制中心类：目标类
abstract class AllyControlCenter
{
    /**
     * 战队名称
     * @var string
     */
    protected $allyName;

    /**
     * 定义一个集合用于存储战队成员
     * @var Observer[]
     */
    protected $players = [];

    /**
     * @param string $allyName
     */
    public function setAllyName(string $allyName): void
    {$this->allyName = $allyName;}

    /**
     * @return string
     */
    public function getAllyName(): string
    {return $this->allyName;}

    // 注册方法
    public function join(Observer $obs): void
    {echo $obs->getName() . 'join the \'' . $this->allyName . '\' ally';
        $this->players[] = $obs;}

    // 注销方法
    public function quit(Observer $obs): void
    {echo $obs->getName() . 'quit the \'' . $this->allyName . '\' ally';
        unset($this->players[array_search($obs, $this->players)]);
    }

    // 声明抽象通知方法
    abstract public function notifyObserver(string $name): void;
}

// 具体战队控制中心类：具体目标类
class ConcreteAllyControlCenter extends AllyControlCenter
{public function __construct(string $allyName)
    {
        echo $allyName . 'is established';
        $this->allyName = $allyName;
    }

    // 实现通知方法
    public function notifyObserver(string $name): void
    {
        echo $this->allyName . 'notify:' . $name . 'is under attacked';
        // 遍历观察者集合，调用每一个盟友（自己除外）的支援方法
        foreach ($this->players as $player) {if ($player->getName() != $name) {$player->help();
            }
        }
    
    }
}

在本实例中，实现了两次对象之间的联动 ，当一个游戏玩家 Player 对象的 beAttacked() 方法被调用时，将调用 AllyControlCenter 的 notifyObserver()方法来进行处理，而在 notifyObserver()方法中又将调用其他 Player 对象的 help()方法。Player 的 beAttacked()方法、AllyControlCenter 的 notifyObserver()方法以及 Player 的 help()方法构成了一个联动触发链，执行顺序如下所示：

Player.beAttacked() –> AllyControlCenter.notifyObserver() –>Player.help()

观察者模式是一种使用频率非常高的设计模式，无论是移动应用、Web 应用或者桌面应用，观察者模式几乎无处不在，它为实现对象之间的联动提供了一套完整的解决方案，凡是涉及到一对一或者一对多的对象交互场景都可以使用观察者模式。观察者模式广泛应用于各种编程语言的 GUI 事件处理的实现，在基于事件的 XML 解析技术（如 SAX2）以及 Web 事件处理中也都使用了观察者模式。

主要优点

观察者模式可以实现表示层和数据逻辑层的分离，定义了稳定的消息更新传递机制，并抽象了更新接口，使得可以有各种各样不同的表示层充当具体观察者角色。
观察者模式在观察目标和观察者之间建立一个抽象的耦合。观察目标只需要维持一个抽象观察者的集合，无须了解其具体观察者。由于观察目标和观察者没有紧密地耦合在一起，因此它们可以属于不同的抽象化层次。
观察者模式支持广播通信，观察目标会向所有已注册的观察者对象发送通知，简化了一对多系统设计的难度。
观察者模式满足“开闭原则”的要求，增加新的具体观察者无须修改原有系统代码，在具体观察者与观察目标之间不存在关联关系的情况下，增加新的观察目标也很方便。

主要缺点

如果一个观察目标对象有很多直接和间接观察者，将所有的观察者都通知到会花费很多时间。
如果在观察者和观察目标之间存在循环依赖，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。
观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。

适用场景

一个抽象模型有两个方面，其中一个方面依赖于另一个方面，将这两个方面封装在独立的对象中使它们可以各自独立地改变和复用。
一个对象的改变将导致一个或多个其他对象也发生改变，而并不知道具体有多少对象将发生改变，也不知道这些对象是谁。
需要在系统中创建一个触发链，A 对象的行为将影响 B 对象，B 对象的行为将影响 C 对象……，可以使用观察者模式创建一种链式触发机制。

架构设计模式观察者模式

概述

案例

总结

主要优点

主要缺点

适用场景

Just My Socks（注册教程内含优惠码）

架构设计模式观察者模式

概述

案例

总结

主要优点

主要缺点

适用场景

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）