《游戏编程模式》读书笔记之一

观察者模式

1、须要注意的地方

同步、异步

（1）对事件同步响应，被观察者有可能会阻塞
（2）对事件异步响应，若是观察者试图得到被观察者的锁，游戏就进入死锁。要使用事件队列来作异步通讯

动态分配内存

（1）观察者列表的添加和删除，须要动态分配内存。

（2）使用链式观察者，无需动态分配内存。当观察者接到通知，它返回了一个标识，代表被观察者是否应该继续遍历观察者列表。这涉及到 职责链模式

销毁被观察者、观察者（云式原则：善始善终原则）

销毁被观察者，须要让观察者接收到一个“死亡通知”，自动取消注册

维基百科有个专门的名字：失效监听者问题

2、时代在变

观察者模式在面向对象编程中大行其道（Java中的java.util.Observer、C#中的delegate/event），但沉重并且死板。

例如：观察者只有一个OnNotify()方法，观察者监听多个被观察者，它不能为不一样的被观察者调用不一样的通知方法

 

做者的观点：

（1）C++克服了在没有垃圾回收语言构建闭包的弱点，甚至Java在JDK8中引入了闭包。（做者很是青睐C++，我也想学）

（2）倾向于注册一个成员函数指针做为观察者，而不是Observer接口的实例

原型模式

彻底没看懂，做者很叼，我须要努力。

单例模式（避免使用）

优势：

全局惟一，须要时再建立实例，可继承

缺点：

（1）因为全局变量，处处被引用，促进耦合，代码理解困难（例如日志类）

（2）每一个线程都能访问，殊不知道其余线程是否正在使用，致使竞争、死锁。

（3）惰性初始化可能发生在游戏的性能高峰期，没法控制

总结：

（1）单例类有时候并不须要，非要装逼。能够使用基类、静态函数等

（2）使用单例，但不必定是全局访问（ 子类沙箱模式）

 

PS.    惰性初始化要注意多线程问题

状态模式

单独写了一篇文章