遊戲開發之路

觀察者模式是甚麼?

用兩個常用的例子解釋:

我是個很親民的超級巨星(目標物件)，所以針對所有在追蹤我的粉絲(觀察者物件)，我都會很開心的主動通知這些粉絲我最新的動態啦

我開了一間報社，發行XX日報(目標物件)，只要是有訂閱日報的讀者(觀察者物件)，報社都會主動發送XX日報給讀者

總而言之 : 就是叫你有事通知他的意思

 舉例來說，假設角色死亡，我們要播放音效、動畫、UI，或者是要存檔，光是這些判斷式就要一堆，還需要有Player的存在，角色也不知到甚麼時候會死，但是如果我們用觀察者模式

可以一行搞定，簡單來說就是一個通知的方法，通知給所有觀察者物件

優點:

•  程式獨立不互相影響
• 擴充性高
• 其他減少耦合性帶來的好處

實做大至分類:

主題類別
Subject { 
    
    Observer觀察者List

    註冊方法

    取消註冊方法

    通知方法<執行Observer的更新方法> 
}

某某主題類別
Subject實例{  //繼承Subject

    override

    其他方法

}

觀察者類別
Observer{

    被通知之後的更新方法

    取得Subject的方法

}

某某觀察者類別
Observer實例{    //繼承Observer

    override<更新方法裡面直接取Subject裡的方法>

    其他方法

}

Code:

• 主題類別

• 主題實作

• 觀察者類別

• 兩個觀察者實作

• 測試觀察者模式

執行結果→

ConcreteObserver1.Update

ConcreteObserver2.Update

ConcreteObserver2:Subject 目前的主題:Subject狀態 1

ConcreteObserver1:Subject 目前的主題:Subject狀態 1

P.S.推拉更新訊息

主題(Subject)在改變的時候，改變內容給觀察者(Observer)得知，而方法有堆訊息拉訊息兩種:

上面觀察者的例子就是 拉訊息 的例子

1. 拉訊息 :
   先通知觀察者(Observer)更新，依照系統需求，向主題(Subject)查詢所需資訊(拉)
   
   優點 : 主題(Subject)通知更新，觀察者(Observer)自己取得需要的資訊，所以比較不會取得不必要的資訊
   
   缺點 : 容易造成主題(Subject)類別介面方法過多 
    
2. 推訊息 :

   更新內容主動(推)給觀察者(Observer)，呼叫觀察者(Observer)的更新方法(Update)時，將更新的內容當成參數傳給觀察者(Observer)

   優點 : 所有內容一次傳送給觀察者(Observer)，省去觀察者(Observer)再向主題(Subject)查詢的動作，主題(Subject)類別也不用定義太多的查詢方法給觀察者(Observer)查詢

   缺點 : 常常收到不必要的資訊或造成查詢困

依需求判斷要用哪個方式