【游戏编程模式】观察者模式
观察者应用广泛，如MVC架构。
Java将其放到了核心库中（
java.util.Observer），而C#直接将其嵌入了语法（event关键字）
案例：成就解锁
假设我们向游戏中添加了成就系统。 它存储了玩家可以完成的各种各样的成就，比如“杀死1000只猴子恶魔”，“从桥上掉下去”，或者“一命通关”。
要实现这样一个包含各种行为来解锁成就的系统是很有技巧的。 举个例子，有物理代码处理重力，追踪哪些物体待在地表，哪些坠入深渊。 为了实现“桥上掉落”的徽章，我们可以直接把成就代码放在那里，但那就会一团糟。 相反，可以这样做：
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_;
};
被观察者
被观察的对象拥有通知的方法函数。 它有两个任务。首先，它有一个列表，保存默默等它通知的观察者：
class Subject
{
private:
Observer* observers_[MAX_OBSERVERS];
int numObservers_;
};
重点是被观察者暴露了公开的API来修改这个列表：
class Subject
{
public:
void addObserver(Observer* observer)
{
// 添加到数组中……
}
void removeObserver(Observer* observer)
{
// 从数组中移除……
}
// 其他代码……
};
这就允许了外界代码控制谁接收通知。 被观察者与观察者交流，但是不与它们耦合。
被观察者有一列表观察者而不是单个观察者也是很重要的。 这保证了观察者不会相互干扰。 举个例子，假设音频引擎也需要观察坠落事件来播放合适的音乐。 如果客体只支持单个观察者，当音频引擎注册时，就会取消成就系统的注册。 支持一列表的观察者保证了每个观察者都是被独立处理的。
被观察者的剩余任务就是发送通知：
class Subject
{
protected:
void notify(const Entity& entity, Event event)
{
for (int i = 0; i < numObservers_; i++)
{
observers_[i]->onNotify(entity, event);
}
}
// 其他代码…………
};
可被观察的物理系统
现在，我们只需要给物理引擎和这些挂钩，这样它可以发送消息， 成就系统可以和引擎连线来接受消息。 我们按照传统的设计模式方法实现，继承Subject：
class Physics : public Subject
{
public:
void updateEntity(Entity& entity);
};
这让我们将notify()实现为了Subject内的保护方法。 这样派生的物理引擎类可以调用并发送通知，但是外部的代码不行。 同时，addObserver()和removeObserver()是公开的， 所以任何可以接触物理引擎的东西都可以观察它。
现在，当物理引擎做了些值得关注的事情，它调用notify()，就像之前的例子。 它遍历了观察者列表，通知所有观察者。
在真实代码中，我会避免使用这里的继承。 相反，我会让Physics 有 一个Subject的实例。 不再是观察物理引擎本身，被观察的会是独立的“下落事件”对象。 观察者可以用像这样注册它们自己：
physics.entityFell().addObserver(this);
对我而言，这是“观察者”系统与“事件”系统的不同之处。 使用前者，你观察做了有趣事情的事物。 使用后者，你观察的对象代表了发生的有趣事情。
链式观察者
我们现在看到的所有代码中，Subject拥有一列指针指向观察它的Observer。 Observer类本身没有对这个列表的引用。 它是纯粹的虚接口。优先使用接口，而不是有状态的具体类，这大体上是一件好事。
但是如果我们确实愿意在Observer中放一些状态， 我们可以将观察者的列表分布到观察者自己中来解决动态分配问题。 不是被观察者保留一列表分散的指针，观察者对象本身成为了链表中的一部分：
为了实现这一点，我们首先要摆脱Subject中的数组，然后用链表头部的指针取而代之：
class Subject
{
Subject()
: head_(NULL)
{}
// 方法……
private:
Observer* head_;
};
然后，我们在Observer中添加指向链表中下一观察者的指针。
class Observer
{
friend class Subject;
public:
Observer()
: next_(NULL)
{}
// 其他代码……
private:
Observer* next_;
};
这里我们也让Subject成为了友类。 被观察者拥有增删观察者的API，但是现在链表在Observer内部管理。 最简单的实现办法就是让被观察者类成为友类。
注册一个新观察者就是将其连到链表中。我们用更简单的实现方法，将其插到开头：
void Subject::addObserver(Observer* observer)
{
observer->next_ = head_;
head_ = observer;
}
另一个选项是将其添加到链表的末尾。这么做增加了一定的复杂性。 Subject要么遍历整个链表来找到尾部，要么保留一个单独tail_指针指向最后一个节点。
加在在列表的头部很简单，但也有另一副作用。 当我们遍历列表给每个观察者发送一个通知， 最新注册的观察者最先接到通知。 所以如果以A，B，C的顺序来注册观察者，它们会以C，B，A的顺序接到通知。
理论上，这种还是那种方式没什么差别。 在好的观察者设计中，观察同一被观察者的两个观察者互相之间不该有任何顺序相关。 如果顺序确实有影响，这意味着这两个观察者有一些微妙的耦合，最终会害了你。
让我们完成删除操作：
void Subject::removeObserver(Observer* observer)
{
if (head_ == observer)
{
head_ = observer->next_;
observer->next_ = NULL;
return;
}
Observer* current = head_;
while (current != NULL)
{
if (current->next_ == observer)
{
current->next_ = observer->next_;
observer->next_ = NULL;
return;
}
current = current->next_;
}
}
如你所见，从链表移除一个节点通常需要处理一些丑陋的特殊情况，应对头节点。 还可以使用指针的指针，实现一个更优雅的方案。
因为使用的是链表，所以我们得遍历它才能找到要删除的观察者。 如果我们使用普通的数组，也得做相同的事。 如果我们使用双向链表，每个观察者都有指向前面和后面的指针， 就可以用常量时间移除观察者。
剩下的事情只有发送通知了，这和遍历列表同样简单；
void Subject::notify(const Entity& entity, Event event)
{
Observer* observer = head_;
while (observer != NULL)
{
observer->onNotify(entity, event);
observer = observer->next_;
}
}
这里，我们遍历了整个链表，通知了其中每一个观察者。 这保证了所有的观察者相互独立并有同样的优先级。 但是，我们牺牲了一些小小的功能特性。
由于我们使用观察者对象作为链表节点，这暗示它只能存在于一个观察者链表中。 换言之，一个观察者一次只能观察一个被观察者。 在传统的实现中，每个被观察者有独立的列表，一个观察者同时可以存在于多个列表中。
你也许可以接受这一限制。 通常是一个被观察者有多个观察者，反过来就很少见了。 可以使用链表节点池的方式来解决这一问题。
链表节点池
就像之前，每个被观察者有一链表的观察者。 但是，这些链表节点不是观察者本身。 相反，它们是分散的小“链表节点”对象， 包含了指向观察者的指针和指向链表下一节点的指针。
由于多个节点可以指向同一观察者，这就意味着观察者可以同时在超过多个被观察者的列表中。 我们可以同时观察多个对象了。
避免动态分配的方法很简单：由于这些节点都是同样大小和类型， 可以预先在对象池中分配它们。 这样你只需处理固定大小的列表节点，可以随你所需使用和重用， 而无需牵扯到真正的内存分配器。
剩余的问题
还有两个挑战，一个是关于技术，另一个更偏向于可维护性。
销毁被观察者和观察者
我们看到的样例代码健壮可用，但有一个严重的副作用： 当删除一个被观察者或观察者时会发生什么？ 如果你不小心在某些观察者上面调用了delete，被观察者也许仍然持有指向它的指针。 那是一个指向一片已释放区域的悬空指针。 当被观察者试图发送一个通知，额……就说发生的事情会出乎你的意料之外吧。
删除被观察者更容易些，因为在大多数实现中，观察者没有对它的引用。 但是即使这样，将被观察者所占的字节直接回收可能还是会造成一些问题。 这些观察者也许仍然期待在以后收到通知，而这是不可能的了。
你可以用好几种方式处理这点。在被删除时取消注册是观察者的职责。 多数情况下，观察者确实知道它在观察哪个被观察者， 所以通常需要做的只是给它的析构器添加一个removeObserver()。
如果在删除被观察者时，你不想让观察者处理问题，这也很好解决。 只需要让被观察者在它被删除前发送一个最终的“死亡通知”。 这样，任何观察者都可以接收到，然后做些合适的行为。
更安全的方案是在每个被观察者销毁时，让观察者自动取消注册。 如果你在观察者基类中实现了这个逻辑，每个人不必记住就可以使用它。 这确实增加了一定的复杂度。 这意味着每个观察者都需要有它在观察的被观察者的列表。 最终维护一个双向指针。
然后呢？
观察者的另一个深层次问题是它的意图直接导致的。 我们使用它是因为它帮助我们放松了两块代码之间的耦合。 它让被观察者与没有静态绑定的观察者间接交流。
当你要理解被观察者的行为时，这很有价值，任何不相关的事情都是在分散注意力。
另一方面，如果你的程序没能运行，漏洞散布在多个观察者之间，理清信息流变得更加困难。 显式耦合中更易于查看哪一个方法被调用了。 这是因为耦合是静态的，IDE分析它轻而易举。
但是如果耦合发生在观察者列表中，想要知道哪个观察者被通知到了，唯一的办法是看看哪个观察者在列表中，而且处于运行中。 你得理清它的命令式，动态行为而非理清程序的静态交流结构。
处理这个的指导原则很简单。 如果为了理解程序的一部分，两个交流的模块都需要考虑， 那就不要使用观察者模式，使用其他更加显式的东西。
当你在某些大型程序上用黑魔法时，你会感觉这样处理很笨拙。 我们有很多术语用来描述，比如“关注点分离”，“一致性和内聚性”和“模块化”， 总归就是“这些东西待在一起，而不是与那些东西待在一起。”
观察者模式是一个让这些不相关的代码块互相交流，而不必打包成更大的块的好方法。 这在专注于一个特性或层面的单一代码块内不会太有用。
这就是为什么它能很好地适应我们的例子： 成就和物理是几乎完全不相干的领域，通常被不同的人实现。 我们想要它们之间的交流最小化， 这样无论在哪一个上工作都不需要另一个的太多信息。
