## 一、觀察者模式 這個模式還有另一個名字發布——訂閱模式。我覺得這個模式跟適合點。 定義了一種一對多的依賴關系，讓多個觀察者對象同時監聽某一個主題對象。這個主題對象在狀態發生變化時，會通知所有觀察者對象，使它們能夠自動更新自己。 這個模式跟我們的博客委員會的職能很相像哦！ 每個月我們都要對博客進行一次檢查。當管理員要結果時，博客委員會組長就得把各自組的博客結果發給管理員。 看一下我們的博客委員會的成立過程： 開始：當每個月底時，管理員會像考勤人員要統計結果。 那管理員怎么通知他們呢？ 一個一個通知他們，讓他們把結果發給管理員。這樣，五個人就需要通知五遍，N個人就要通知N遍嗎？顯然不行。 建立一個飛信群——博客管理，把相關人員加入，直接在群里發一個通知，被加入群的人就可以收到通知，然后把整理結果發送。 接著：由于各種原因，現在管理人員需要2名，又增加一名監督人員，負責對考勤人員監督；照葫蘆畫瓢，我們可以讓新增的管理人員模仿老管理人員，也建個群，也把這些人加進去；同時，還需要在群里增加監督人員。到月底時，管理員發送通知，考勤組和監督組分別執各自任務。 這樣做目的達到！就是有點小問題，管理員得交給新管理員怎么做。假如急需要結果，管理員不在，怎么辦，這樣是不是很不靈活；要是再多一個小組呢？這個小組在接收到群消息時，應該做什么。這時候我們就需要考慮建立一個抽象模板，讓每一個新加的管理員都按照模板的章程來辦事，就不需要向非得等管理員了；給各個小組建立一個頭目，讓這個頭目來對各個小組進行管理，只要把結果發給管理員即可，這就是博客委員會了。 怎么樣？是不是發現，原來我們一直都在用觀察者模式辦事呢？只是不知道它還有一個這樣的學名。 通知，接收，為了讓各個對象耦合度降低，我們都抽象出一個類。 看一下類圖，看看是不是這回事呢？ ## 二、類圖