游戏编程模式:观察者模式

在对象间定义一种一对多的依赖关系,以便当某对象的状态改变时,与它存在依赖关系的所有对象都能收到通知并自动进行更新。

模式动机:

建立一种对象与对象之间的依赖关系,一个对象发生改变时将自动通知其他对象,其他对象将相应做出反应。在此,发生改变的对象称为观察目标,而被通知的对象称为观察者,一个观察目标可以对应多个观察者,而且这些观察者之间没有相互联系,可以根据需要增加和删除观察者,使得系统更易于扩展。

模式定义:

定义对象间的一种一对多依赖关系,使得每当一个对象状态发生改变时,其相关依赖对象皆得到通知并被自动更新。观察者模式又叫做发布-订阅(Publish/Subscribe)模式、模型-视图(Model/View)模式、源-监听器(Source/Listener)模式或从属者(Dependents)模式。

模式结构:

包含以下四个对象:

  • Subject: 目标
  • ConcreteSubject: 具体目标
  • Observer: 观察者
  • ConcreteObserver: 具体观察者

实现方法:

接受通知的对象称为观察者,我们设计一个接口,任何实现这个接口的具体类都会成为一个观察者,接口中主要的方法有:

  • 注册成为观察者的方法
  • 对不同事件的响应方法

发出通知的对象称为被观察者,具有一个通知方法,同时拥有观察者的一个列表和一个用来修改观察者列表的公有API。

这个集合的存在使得让每个观察者都互不干扰,在它们各自的眼里,都认为被观察者对象眼里只有它自己。

优点

  • 观察者模式可以实现表示层和数据逻辑层的分离,并定义了稳定的消息更新传递机制,抽象了更新接口,使得可以有各种各样不同的表示层作为具体观察者角色。
  • 观察者模式在观察目标和观察者之间建立一个抽象的耦合。
  • 观察者模式支持广播通信。
  • 观察者模式符合“开闭原则”的要求。

缺点:

  • 它太慢了:如果一个观察目标对象有很多直接和间接的观察者的话,将所有的观察者都通知到会花费很多时间。
  • 如果在观察者和观察目标之间有循环依赖的话,观察目标会触发它们之间进行循环调用,可能导致系统崩溃。

一些改良:

链式观察者:

原本的观察者使用固定大小的数组或者动态分配内存的集合,当添加或删除观察者的时候,该集合会动态的扩展或者收缩。

我们可以通过一个链表来解决动态分配内存的问题:

  • 注册新的观察者,就将其放在链表头部(尾部也可以,但要额外维护一个尾指针)
  • 删除特定节点可能会遍历整个链表,但是可以使用双向链表来在常量时间内删除一个节点(?)

链表节点池:

每一个被观察者对象都维护一个观察者列表,但是现在的链表节点不是观察者本身,而是一个指向观察者对象的指针和指向下一个节点的指针。这样一来,多个链表节点可以指向同一个观察者,意味着一个观察者可以同时观察多个被观察者对象。

由于所有的节点都是同样的大小和类型,因此可以预分配一个内存对象池(?),这样就有了一个固定大小的链表对象池。

销毁被观察者和观察者:

  1. 当一个观察者对象被删除时,观察者本身应该负责将其从被观察者对象的列表中移除。
  2. 当一个被观察者对象被移除时,被观察者可以向所有的观察者发送一个死亡通知。

总结:

  • 观察者模式包含四个角色:目标又称为主题,它是指被观察的对象;具体目标是目标类的子类,通常它包含有经常发生改变的数据,当它的状态发生改变时,向它的各个观察者发出通知;观察者将对观察目标的改变做出反应;在具体观察者中维护一个指向具体目标对象的引用,它存储具体观察者的有关状态,这些状态需要和具体目标的状态保持一致。
  • 观察者模式定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个目标对象,当这个目标对象的状态发生变化时,会通知所有观察者对象,使它们能够自动更新。
  • 观察者模式的主要优点在于可以实现表示层和数据逻辑层的分离,并在观察目标和观察者之间建立一个抽象的耦合,支持广播通信;其主要缺点在于如果一个观察目标对象有很多直接和间接的观察者的话,将所有的观察者都通知到会花费很多时间,而且如果在观察者和观察目标之间有循环依赖的话,观察目标会触发它们之间进行循环调用,可能导致系统崩溃。
  • 观察者模式适用情况包括:一个抽象模型有两个方面,其中一个方面依赖于另一个方面;一个对象的改变将导致其他一个或多个对象也发生改变,而不知道具体有多少对象将发生改变;一个对象必须通知其他对象,而并不知道这些对象是谁;需要在系统中创建一个触发链。