《游戏编程模式》学习笔记（四） 观察者模式 Observer Pattern

定义

观察者模式定义了对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。

这是定义，看不懂就看不懂吧，我接下来举个例子慢慢说

为什么我们需要观察者模式

我们看一个很简单的需求，现在要你在游戏中加入成就系统，在物体坠落1000米的时候给玩家发一个成就勋章，你要这么做？

最直观的方法就是，在游戏的物理系统那一部分中，加入这么一段代码：

void Physics::updateEntity(Entity& entity)
{bool wasOnSurface = entity.isOnSurface();entity.accelerate(GRAVITY);entity.update();if (wasOnSurface && !entity.isOnSurface()){if (surface.height - entity.height > 1000){//解锁成就unlockFallOffBridge();}}
}

咋一看是不是还行？就加了几行而已。
那么如果我还要求你播放坠落音效呢？是不是还得这样写：

void Physics::updateEntity(Entity& entity)
{bool wasOnSurface = entity.isOnSurface();entity.accelerate(GRAVITY);entity.update();if (wasOnSurface && !entity.isOnSurface()){if (surface.height - entity.height > 1000){//解锁成就unlockFallOffBridge();//播放音效playfallmusic();}}
}

这样看也还行，那如果组长让你根据物体撞击不同的地面，播放不同的地面音效，那这段代码是不是又得膨胀了：

void Physics::updateEntity(Entity& entity)
{bool wasOnSurface = entity.isOnSurface();entity.accelerate(GRAVITY);entity.update();if (wasOnSurface && !entity.isOnSurface()){if (surface.height - entity.height > 1000){//解锁成就unlockFallOffBridge();//播放音效if (hitground){playhitgroundmusic();}if (hitwater){playhitwatermusic();}//.....}}
}

要知道，这可是在你的游戏的物理引擎中，我们并不想看到在处理撞击代码的线性代数时， 有出现关于成就系统，音效系统的调用是不？我们喜欢的是，照旧，让关注游戏一部分的所有代码集成到一块。我们想要解耦物理系统和这些不相关的东西。

这就是观察者模式出现的原因。 这让代码宣称有趣的事情发生了，而不必关心到底是谁接受了通知。

一旦你使用了观察者模式，你的代码就会变成这样：

void Physics::updateEntity(Entity& entity)
{bool wasOnSurface = entity.isOnSurface();entity.accelerate(GRAVITY);entity.update();if (wasOnSurface && !entity.isOnSurface()){notify(entity, EVENT_START_FALL);}
}

是不是简洁了很多很多？比刚才那一大堆丑陋的代码好看多了。

观察者模式做的就是声称，“额，我不知道有谁感兴趣，但是这个东西刚刚掉下去了。做你想做的事吧。”

可能有人会说，诶，这也没有完全解耦啊。的确，物理引擎确实决定了要发送什么通知，所以这并没有完全解耦。但在架构这个领域，通常只能让系统变得更好，而不是完美。

如何构建观察者模式？

最传统的构建方式就是这样，使用对象模式构建观察者

我们先写一个基础的观察者抽象基类

class Observer
{
public:virtual ~Observer() {}virtual void onNotify(const Entity& entity, Event event) = 0;
};

然后让我们的成就系统和音效系统等想成为观察者的系统都继承这个基类：

class Achievements : public Observer
{
public:virtual void onNotify(const Entity& entity, Event event){switch (event){case EVENT_ENTITY_FELL:if (entity.isHero() && heroIsOnBridge_){unlock(ACHIEVEMENT_FELL_OFF_BRIDGE);}break;// 处理其他事件，更新heroIsOnBridge_变量……}}private:void unlock(Achievement achievement){// 如果还没有解锁，那就解锁成就……}bool heroIsOnBridge_;
};

对于被观察者，如物理系统中，我们只要让它持有这个observer的指针就好了，一旦出现了某些事件，我们就给这些指针指向的observer发消息。
为了正式一点，让所有可能的系统都成为被观察者，我们写一个叫subject的基类，让所有想成为被观察者的系统都可以继承这个基类来成为被观察者。

class Subject
{
public:void addObserver(Observer* observer){// 添加到数组中……}void removeObserver(Observer* observer){// 从数组中移除……}void removeObserver(Observer* observer){// 从数组中移除……}
protected:void notify(const Entity& entity, Event event){for (int i = 0; i < numObservers_; i++){observers_[i]->onNotify(entity, event);}}private:Observer* observers_[MAX_OBSERVERS];int numObservers_；
};

我们可以看见，这里写了一个观察者数组，存了许多观察者的指针，这是因为大部分情况下，被观察者可能会有好多个观察者观察着它。然后我们也写了一些方法来增删这个数组。

然后就是面向对象的东西了，我们让物理系统继承这个基类

class Physics : public Subject
{
public:void updateEntity(Entity& entity);
};

现在，当物理引擎做了些值得关注的事情，它调用notify()，就像之前的例子。 它遍历了观察者列表，通知所有观察者。

恭喜你已经掌握了如何写一个观察者模式，你所看到的就是一个观察者模式的全部。现在来回顾一下定义：

观察者模式定义了对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。

是不是有点明白了？

**

观察者模式的使用场合

**

当一个抽象模式有两个方面，其中一个方面依赖于另一个方面，需要将这两个方面分别封装到独立的对象中，彼此独立地改变和复用的时候。
当一个系统中一个对象的改变需要同时改变其他对象内容，但是又不知道待改变的对象到底有多少个的时候。
当一个对象的改变必须通知其他对象作出相应的变化，但是不能确定通知的对象是谁的时候。

观察者模式的缺点：

1. 由于观察者模式调用了一些虚方法，终究会比静态调用慢一些。
2. 观察者模式是同步的。 被观察者直接调用了观察者，这意味着直到所有观察者的通知方法返回后， 被观察者才会继续自己的工作。观察者会阻塞被观察者的运行。
3. 由于被观察者维护了一个数组来存储观察者指针，在实际情况中一般会用动态数组而不是这次例子中的静态数组。这样就会做出太多的动态分配。解决方法还是有的，那就是使用链表而不是数组来存储观察者指针（反正你都得遍历发通知，这俩差不多）。

原文链接：https://gpp.tkchu.me/observer.html