這一篇我們將來學習觀察者模式，在Cocos2d-x中應用此模式的典型類是CCNotificationCenter，個人感覺MFC中的消息機制和這個模式很相似，觀察者可以註冊自己所關心的目標，一旦目標發生某種改變就會遍歷註冊過它的所有觀察者，並向關心此變化的觀察者推送對應的消息（CCNotificationCenter爲直接顯式發送），觀察者在接收到消息後會調用相關響應函數。
【轉載自子龍山人】：http://zilongshanren.com/blog/2012/10/29/cocos2d-x-design-pattern-6-observer/
1、應用場景
前面在介紹單例模式的時候，提到了一個類CCNotificationCenter，它除了應用單例模式以外，還應用了觀察者模式。CCNotificationCenter類是觀察者模式中的目標對象，而CCNotificationObserver則是觀察者。
一個目標對象可以註冊多個觀察者，當目標對象的狀態改變的時候，可以通知觀察者對象作出相應的響應。這是標準的觀察者模式的實現，但是CCNotificationCenter稍微有些許差別。
首先，CCNotificationCenter不是通過自身狀態改變來通知觀察者，而是通過顯式地發送觀察者感興趣的消息（postNotification）來通知它們。每一種消息類型可以對應多個觀察者，同時，每一個觀察者也可以“觀察”多個消息類型。其次，觀察者定義相應的響應事件同消息類型關聯，當某個地方觸發postNotification來廣播一個消息的時候，CCNotificationCenter會遍歷所有的觀察者，判斷它們註冊的消息類型是否匹配，如果匹配，則觸發相應的註冊響應事件。最後，該觀察者模式採用的是推模型，即由目標對象去通知所有的觀察者。
其實CCNotificationCenter和CCNotificationObserver更準確的叫法是：訂閱發佈模式。
2、使用此模式的優缺點
優點：
1）實現了目標對象和觀察者之間的抽象耦合，在本例中，則是實現了消息與觀察者的抽象耦合。可以定義一種消息與消息處理對象的一對多的關係，而不用擔心彼此的實現細節。
2）觀察者模式可以定義某種意義上的廣播通信機制。
3）實現訂閱者與發佈者的鬆散耦合，同時保障了良好的擴展性。
缺點：
1）註冊成爲CCNotificationCenter的觀察者後，如果忘記調用removeObserver，則會引起內存泄漏。因爲addObserver會把觀察者的引用計算加1.
3、此模式的定義及一般實現
定義：
定義對象間的一種一對多的依賴關係，當一個對象的狀態發生改變時，所有依賴於它的對象都得到通知並被自動更新。
UML圖：
一般實現：參考CCNotificationCenter.h和CCNotification.cpp文件的實現
4、遊戲開發中如何運用此模式
我們考慮cocos2d-x中一個非常典型的應用場景，你的GameScene裏面有兩個layer，一個gameLayer，它包含了遊戲中的對象，比如玩家、敵人等。另一個層是HudLayer，它包含了遊戲中顯示分數、生命值等信息。如何讓這兩個層相互通信。
第一種辦法，你可以讓gameLayer包含一個hudLayer的引用，同時也可以讓hudLayer包含一個gameLayer的引用。注意！這裏問題出現了，如果兩個類都包含彼此的強引用（所謂強引用就是retain），就會引起循環引用的情況，如果其中一個類包含的是弱引用，問題就不會出現。循環引用是使用引用計數管理內存的一個致命弱點，會導致資源永遠得不到釋放，而且查錯起來非常麻煩。
第二種辦法，把gameScene做成一個單例，同時讓gameScene包含gameLayer和hudLayer的弱引用，這樣就可以直接通過[GameScene sharedInstance].gameLayer或者[GameScene sharedInstance].hudLayer來訪問了。
第三種辦法，使用gameLayer->getParent()獲得gameScene，再使用gameScene來獲得hudLayer。
第四種辦法，使用CCNotificationCenter。當hudLayer註冊它感興趣的消息，當gameLayer需要通知hudLayer的時候，只需通過CCNotificationCenter發送一個對應的消息即可。
5、此模式與其它模式的關係
觀察者模式是實現MVC模式的重要組成部分，一個model可以對應多個views，model就是目標對象，而view則是觀察者，當model改變的時候，要通知所有的view也相應的改變。