摘要:深入淺出設計模式讀後心得_觀察者模式
觀察者模式：
定義了對象之間的一對多依賴，這樣一來，當一個對象改變狀態時，它的所有依賴者都會收到通知並自動更新
簡單的說：就是需要資料的人去跟管理者登記，登記完之後，由管理者統一發送資料，就像讀者向報社訂報紙一樣
從以上的目的而設計了一個ISubject介面，也就是所有主題管理者都應該具體實做的介面，如下：
這個介面裡面基本上要定義加入觀察者的方法(AddObserver)、刪除觀察者的方法(DelObserver)和
通知所有觀察者的方法(NotifyObservers)
而觀察者基本上也要定義觀察者的介面，如下：
最起碼要定義一個更新觀察者自己的update方法，才能讓主題管理者通知觀察者做更新
之所以要做這些介面，就是不要讓主題管理者和觀察者之間有依賴，可以：
1.隨時增加觀察者
2.用新的觀察者取代舊的觀察者
3.隨時刪除觀察者
以上的變更都不會影響主題管理者...
設計原則：為了交互對象之間的鬆藕合設計而努力
在設計主題管理者的NotifyObservers方法和觀察者的Update方法要思考一下參數的"推"與"拉"
推：就是定義方法時有定義方法的引數，如：Update(object[] args)
拉：就是定義方法時不定義方法的引數，如：主題管理者利用觀察者的Update方法要觀察者更新，此時的Update不傳入任何參數，由實作的觀察者自行向主題管理者"拉"資料，像下圖紅框所示
由擔任主題管理者的ChatRoom類別提供GetMessage方法，讓下面的Visitor觀察者類別"拉"資料
最後要注意的是：不要依賴於觀察者被通知的順序
鬆藕合的設計不應該因為改變了順序就引發未預期的行為
目前自己對鬆藕合還不夠熟練，常常寫一寫就寫出綁來綁去的情形而沒發覺，看來要"寫好程式"還是要在設計時及寫完後多思考才行
其實工作上也不必一定要"完全套用"某個設計模式，重要的應該是對各個設計模式熟悉
熟悉到在設計程式架構時，能讓自己寫的程式有適度的彈性並符合需求、保持可維護性，這樣也就足夠了吧...
雖然有找到.Net也有弄了一個IObservable，但是卻要4.0才有，所以這邊就全部自己寫了
有機會再來看看.Net的IObservable定義了些什麼
附上實作程式碼：Observer Pattern Sample.rar
這個程式碼寫的是用來自High的聊天室，所以基本上就是開出訪客視窗，當其中一個訪客發送訊息給主題管理者時，主題管理者就通知所有其它的訪客視窗更新畫面，所以每個訪客既是觀察者，也會是通知主題管理者要發佈更新的人
(沒辦法...真的想不到什麼比較簡單的題目來實作這個模式了Orz，若寫得不好還請各位看倌給個建議囉^^)
