設計模式之觀察者模式（三）

又和大家見面了。首先，和大家說聲抱歉，之前的幾篇文章，可能條理清晰之類的做的不太好，每篇文章的篇幅也比較長，小編在收到讀者的建議之後，也是認真的思考了一番。之前的想法是盡量把一個子產品介紹完，沒想到一個子產品寫着寫着就寫長了。在之後的文章裡，需要認真分段，做到能簡潔就簡潔，能分塊就分塊，在利用大家碎片化的時間裡，力争短小精悍又能收獲頗豐。

之前的觀察者模式，介紹了自己動手編寫一套觀察者模式，以及使用Java内置的觀察者模式來進行實作。分了兩篇，并且知道了，觀察者模式是基于釋出和訂閱的，主要由兩種模式

拉模式

目标角色發生變化之後，僅僅告訴觀察者角色已經發生變化了；觀察者角色如果想要知道更詳細的内容以及變化細節，就需要自己去擷取，比如通過getter方法。
推模式

通知你發生變化的同時，把變化的資訊發送到觀察者角色中去。推模式就是無論觀察者是否需要這個資訊，都會無條件的收到。

這兩種模式的使用，取決于功能需求。如果目标角色錯綜複雜，并且觀察者角色進行更新時必須得到一些具體變化的資訊，那就适合用“推”；如果目标角色簡單，又不需要每次都擷取變化資訊，那就用“拉”。

在JDK中，也有觀察者模式的實際使用場景。比如Swing API的JButton。JButton的超類AbstractButton中有許多增加和删除（listener）的方法，其實就是觀察者模式的提現。考慮到現在Swing的實際使用場景并不多，在這裡就不進行贅述啦，感興趣的朋友可以看看Java源代碼，或者去實踐下。

設計箱内的工具

這個工具其實在之前政策模式的時候總結過，但是并沒有通過标題的方式單獨給大家介紹，在之後的總結裡，把這個單獨加上，這個還是比較重要的。我們通過一步一步的學習，積累一個個工具，設計模式就不會很難啦。

OO基礎

抽象、封裝、繼承、多态
OO原則

封裝變化

多用組合，少用繼承

針對接口程式設計，不針對實作程式設計

為互動對象之間的松耦合設計而努力（這是本次的新原則。松耦合設計更有彈性，更能應對變化）
OO模式

『政策模式』

『觀察者模式』--在對象之間定義一對多的依賴，這樣一來，當一個對象改變狀态，依賴它的對象就會收到通知，并自動更新。（就是我們新學習的模式，以松耦合方式在系列對象之間溝通狀态。MVC是觀察者模式的代表，後續會有機會介紹的哦）

挑戰設計原則

這次也涉及到了設計原則，之前沒有過多的介紹。那麼，觀察者模式是如何遵循設計原則的呢？别急，馬上給你

找出程式中會變化的方面，然後将其和固定不變的方面相分離

在觀察者模式中，會改變的是主題的狀态，以及觀察者的數目和類型。用這個模式，你可以改變依賴于主題狀态的對象，卻不必改變主題。這就叫提前規劃！

針對接口程式設計，不針對實作程式設計

主題與觀察者都是用接口；觀察者利用主題的接口向主題注冊，而主題利用觀察者接口通知觀察者。這樣可以讓兩者之間運作正常，又同時具有松耦合的優點

多用組合，少用繼承

觀察者模式利用“組合”将許多觀察者組合進主題中。對象之間的這種關系不是通過繼承産生的，而是在運作時利用組合的方式而産生的。

至此，小編就學完了觀察者模式。相比較于書本，小編把觀察者模式的其中一些更好的概念了解縮減了，隻單獨舉了一個報社訂閱報紙的例子來做進一步的解釋。以及模式中的“推”和“拉”是如何引出而來的，也沒有細說，在這節裡把推和拉的特點進行了描述，并給出了一點拙見。

有留言給小編說圖的來源，以及是否需要有畫圖的能力。我把我在知識星球裡的回答放出來，隻是自己的一點感悟，如有不對的地方，可以留言給小編修正。『設計模式歸根到底還是需要一個思想，畫UML圖是為了更加深刻了解軟體工程中的知識。優秀的寫代碼的程式員不一定能畫好UML圖，能畫好UML的一定是個優秀的程式員（我是這麼了解的），很多公司都不需要畫圖，因為隻要實作功能即可，這個能力，需要自己平時培養的。我畫UML圖也不太好，還停留在大學老師教育的階段，是以跟着這個學習，畫圖了解能力還提升了，也是另一種收獲吧。類圖、時序圖、用例圖都是比較重要的，掌握了能加深對軟體工程的了解』

觀察者模式就到這裡為止了。下一模式是裝飾者模式，就如開頭所說，小編會用心分塊，力争短小精悍，讓各位的碎片化時間得到更充分的利用。

設計模式之觀察者模式（三）