GOF的設計模式中是這樣描述Observer模式的意圖(intent)的：
定義對象間的一種一對多的依賴關系，當一個對象的狀態發生改變時，所有依賴于它的對象都得到通知并被自動更新。

我自己的理解是：
??????? Observer模式定義了一種多個對象之間的一對多的相互依賴關系,當一個對象的狀態發生改變時,其他與之有關系的對象“看上去”都要相應采取行動。


試著用Observer模式寫了一些代碼，模擬灌籃比賽，運動員每次灌完之后，評委為他們打分。
在這里Player是Subject；
ChinesePlayer和USPlayer是ConcreteSubject；
Rater是Observer
DunkRater是ConcreteObserver

Player中的endPlaying方法就是Player的行為或(引起觀察者行為的)事件。
Rater中的rate方法是觀察者的響應行為。???????????

?????????

某一次打印出的結果如下：
Yao Ming have a power dunk
Kobe: 4
Jordan: 4
James have a highflyer dunk
Kobe: 7
Jordan: 5

??
?幾點討論：

1)在Player(Subject)中的那個raterList是否可以把private改為protected?
?? 我覺得改了不好，因為不應該把“用什么數據結構、何種方式保存Rater(Observer)”暴露給用戶。(客戶程序員，他們可以擴展Player這個抽象類)，否則就違背了封裝性。

2)從面向對象的幾個原則來看Observer模式
??? a)把變化的部分封裝起來：
?????? 我們可以很好地擴展Player和Rater兩個部分，彼此沒有過多影響。因此Observer模式在方面做的還是很好的。
????? ConcretePlayer與ConcreteRater這間的聯系就是ConcretePlayer維護著一個注冊過的現有的Rater(Observer)的列表(這個列表的實現方式對于負責擴展地程序員應該是透明的)，ConcretePlayer不知道它的監聽者具體是什么類型，只知道它們實現了Rater(Observer)的接口。
???????

??? b)面向接口編程而不是面向實現
????? 在客戶主程序中，只出現了三個具體的類，這樣的問題可以通過工廠模式解決。
????? 值得注意的一點，也是Head First in Design Patterns中對于這條原則的一個解釋：
??????一直以來我們所說的面向對象設計中很重要的一條原則－－面向接口編程，再加之繼承存在的種種問題，容易使人產生錯覺：使用關鍵字interface。
????? 實際上這條原則的一個等價的說法是“面向SuperType編程”。這里的SuperType的意思是接口或者超類。
????? 因此用abstract class并沒有違反這樣的原則，反而是遵守了。

3)語義上與實現上是否是相反的
???我不明白是翻譯問題還是我自己沒懂，總覺得GOF的描述中“自動”二字和“觀察者”會給讀者帶來誤解。
???原因如下：
??????? Observer模式描述的是這樣的一種情況：
????????當一個Subject的狀態發生變化或被觸發了一個事件的時候，在這個Subject上注冊的對象要依據這樣的變化或事件做出相應的反映，這些對象然后被稱之為Observers。
????????按照GOF的說法，從語義上來說應該是Observer主動響應了這個行為。
??????? 但在實現上應該是Subject調用Observer的這個響應行為，這就是我上面所說的“看上去”主動響應，實際上是被動地被Subject調用。
??????? 因此Observer和自動不免給人帶來誤解，站在Subject的角度上給這個模式取名，叫作通知者模式也許更好。
????????
????????
??????? 這個例子，以后會重構，將其他模式應用上去。在網上學習的過程中，知道Observer模式和責任鏈模式、MVC模式會有組合，但我現在還沒有學到，就先寫這些吧。
????????

???????


??????
??
?



????????
???????
?????????
?

<fieldset id="cs8e2"></fieldset>