观察者模式
一、需要注意的地方
同步、异步
（1）对事件同步响应，被观察者有可能会阻塞
（2）对事件异步响应，如果观察者试图获得被观察者的锁，游戏就进入死锁。要使用事件队列来做异步通信
（2）对事件异步响应，如果观察者试图获得被观察者的锁，游戏就进入死锁。要使用事件队列来做异步通信
动态分配内存
（1）观察者列表的添加和删除，需要动态分配内存。
（2）使用链式观察者，无需动态分配内存。当观察者接到通知，它返回了一个标识，表明被观察者是否应该继续遍历观察者列表。这涉及到
职责链模式
销毁被观察者、观察者（云式原则：有始有终原则）
销毁被观察者，需要让观察者接收到一个“死亡通知”，自动取消注册
*有个专门的名字：失效监听者问题
二、时代在变
观察者模式在面向对象编程中大行其道（Java中的java.util.Observer、C#中的delegate/event），但沉重而且死板。
例如：观察者只有一个OnNotify()方法，观察者监听多个被观察者，它不能为不同的被观察者调用不同的通知方法
作者的观点：
（1）C++克服了在没有垃圾回收语言构建闭包的弱点，甚至Java在JDK8中引入了闭包。（作者非常青睐C++，我也想学）
（2）倾向于注册一个成员函数指针作为观察者，而不是Observer接口的实例
原型模式
完全没看懂，作者很叼，我需要努力。
单例模式（避免使用）
优点：
全局唯一，需要时再创建实例，可继承
缺点：
（1）由于全局变量，到处被引用，促进耦合，代码理解困难（例如日志类）
（2）每个线程都能访问，却不知道其他线程是否正在使用，导致竞争、死锁。
（3）惰性初始化可能发生在游戏的性能高峰期，无法控制
总结：
（1）单例类有时候并不需要，非要装逼。可以使用基类、静态函数等
（2）使用单例，但不一定是全局访问（
子类沙箱模式）
PS. 惰性初始化要注意多线程问题
状态模式
单独写了一篇文章