《遊戲編程模式》讀書筆記之一

觀察者模式

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.    惰性初始化要注意多線程問題

狀態模式

單獨寫了一篇文章