場景
王大哥收到用戶的需求，要做一套訂閱系統(tǒng)，類似一個博主，多個粉絲那種。
于是王大哥扣了扣腦袋，想到了三個方法：
方案一：粉絲不斷的get博主的狀態(tài)，從而得到其更新的內(nèi)容。
評價：fans需要不斷的查詢，對比更新前后內(nèi)容。效率低
方案二：當博主更新時，博主會通知粉絲，粉絲自己來獲得更新內(nèi)容。
評價：fans需要隨時關(guān)注來自博主的提示，來判斷是否更新。本來是博主自己的事情，卻需要兩個人來做。
方案三：當博主更新時，博主會推送更新的內(nèi)容給粉絲
評價：博主有新發(fā)布后，通知fans并調(diào)用fans的update()，實現(xiàn)了fans的自動更新。
方案三采用了觀察者模式，做到了盡量解耦合，同時提高效率。
這時，王大哥又收到了新的需求：根據(jù)博主的信息，用戶可以不看的相關(guān)的推送。按照方案三，只需要更改用戶的設(shè)置即可。
總結(jié)
意圖：在對象之間定義一種一對多的依賴關(guān)系，這樣當一個對象的狀態(tài)改變時，所有依賴者都將得到通知并自動更新。
問題：當某個事件發(fā)生時，需要向一系列變化著的對象發(fā)出通知。
解決方案：observer將監(jiān)視某個事件的責任委托給中心對象：subject。
效果：如果某些observer只對事件的一個子集感興趣，那么subject可能會告訴他們不需要知道的事情。
實現(xiàn)：
- 讓某個事件發(fā)生時需要知道的對象將自己注冊到另一個監(jiān)視事件發(fā)生或者自己觸發(fā)事件的對象上。
- 事件發(fā)生時，Subject告訴Observer事件已經(jīng)發(fā)生。
- 為了對所有的Observer類型對象實現(xiàn)Observer接口，有時候需要使用Adapter模式。
當某件事情發(fā)生時，要向一系列變化的對象發(fā)出通知時，才最適用觀察者。
某些觀察者有的時候只需要處理一些固定的情況，那我們就可以配合strategy模式一起使用。
通過添加或者刪除已經(jīng)組合的對象，可以靈活的修改代碼，而不需要去修改內(nèi)部代碼。
