原文首發(fā)于我的微信公眾號：GeekArtT.
Observer設計模式是為了解決“信息同步更新”的問題而存在的。它試圖解決這樣一個問題：如果有“一堆對象”都跟隨“某一對象”的變化而變化，那么，如何能夠保持“這堆對象”能夠同步更新呢？特別是，“這堆對象”很可能在運行時（run-time）不斷被添加或者被刪除，你設計的機制該如何既能保持增添/刪除的靈活性，而又能使“當前這堆對象”同步更新呢？
僅僅是抽象地看待上述這個問題，或許很難有思路。解決方案的形成可以依托于生活中具體業(yè)務場景的類比。
很多書籍介紹觀察者（Observer）這個設計模式喜歡運用“內(nèi)容訂閱者”和“發(fā)布信息平臺”的對應關系。這個比喻從生產(chǎn)流程上講，完全符合，但是作為比喻，還是顯得有些生硬。我認為，一個更好的、更富有啟發(fā)性的類比是“品牌商店”與“旗下加盟商/分店”在價格上的依存關系。好不夸張的說，一旦做出這個類比，解決方案就會自然浮現(xiàn)。
例如，McDonald在一座城市開店，其價格都是高度統(tǒng)一。如果某一個分店的價格低于別的分店，就會打亂跨國大公司的整體戰(zhàn)略部署，是絕不允許的。所以，一個核心的目標是，每一個分店的價格都必須時刻同步統(tǒng)一。另一方面，每個地區(qū)的分店，都有可能隨著市場的反饋而做出調(diào)整：或者因為銷量過低而關閉，或者因為某個新的商圈的出現(xiàn)而增加分店。那么，在分店的數(shù)目、位置都在隨時變動的情形下，應該用一套什么機制才能保證分布在城市各地的分店都使用統(tǒng)一的價格呢？<
