又和大家見面了。首先，和大家說聲抱歉，之前的幾篇文章，可能條理清晰之類的做的不太好，每篇文章的篇幅也比較長，小編在收到讀者的建議之後， 也是認真的思考了一番。之前的想法是儘量把一個模塊介紹完，沒想到一個模塊寫著寫著就寫長了。在之後的文章里，需要認真分段，做到能簡潔就簡潔，能分塊就分塊，在利用大家碎片 ...
又和大家見面了。首先，和大家說聲抱歉，之前的幾篇文章，可能條理清晰之類的做的不太好，每篇文章的篇幅也比較長，小編在收到讀者的建議之後， 也是認真的思考了一番。之前的想法是儘量把一個模塊介紹完，沒想到一個模塊寫著寫著就寫長了。在之後的文章里，需要認真分段，做到能簡潔就簡潔，能分塊就分塊，在利用大家碎片化的時間里，力爭短小精悍又能收穫頗豐。
之前的觀察者模式，介紹了自己動手編寫一套觀察者模式，以及使用Java內置的觀察者模式來進行實現。分了兩篇，並且知道了，觀察者模式是基於發佈和訂閱的，主要由兩種模式
- 拉模式
目標角色發生變化之後，僅僅告訴觀察者角色已經發生變化了；觀察者角色如果想要知道更詳細的內容以及變化細節，就需要自己去獲取，比如通過getter方法。 - 推模式
通知你發生變化的同時，把變化的信息發送到觀察者角色中去。推模式就是無論觀察者是否需要這個信息，都會無條件的收到。
這兩種模式的使用，取決於功能需求。如果目標角色錯綜複雜，並且觀察者角色進行更新時必須得到一些具體變化的信息，那就適合用“推”；如果目標角色簡單，又不需要每次都獲取變化信息，那就用“拉”。
在JDK中，也有觀察者模式的實際使用場景。比如Swing API的JButton。JButton的超類AbstractButton中有許多增加和刪除（listener）的方法，其實就是觀察者模式的提現。考慮到現在Swing的實際使用場景並不多，在這裡就不進行贅述啦，感興趣的朋友可以看看Java源代碼，或者去實踐下。
設計箱內的工具
這個工具其實在之前策略模式的時候總結過，但是並沒有通過標題的方式單獨給大家介紹，在之後的總結里，把這個單獨加上，這個還是比較重要的。我們通過一步一步的學習，積累一個個工具，設計模式就不會很難啦。
OO基礎
抽象、封裝、繼承、多態
OO原則
封裝變化
多用組合，少用繼承
針對介面編程，不針對實現編程
為交互對象之間的松耦合設計而努力（這是本次的新原則。松耦合設計更有彈性，更能應對變化）
OO模式
『策略模式』
『觀察者模式』--在對象之間定義一對多的依賴，這樣一來，當一個對象改變狀態，依賴它的對象就會收到通知，並自動更新。（就是我們新學習的模式，以松耦合方式在系列對象之間溝通狀態。MVC是觀察者模式的代表，後續會有機會介紹的哦）
挑戰設計原則
這次也涉及到了設計原則，之前沒有過多的介紹。那麼，觀察者模式是如何遵循設計原則的呢？別急，馬上給你
- 找出程式中會變化的方面，然後將其和固定不變的方面相分離
在觀察者模式中，會改變的是主題的狀態，以及觀察者的數目和類型。用這個模式，你可以改變依賴於主題狀態的對象，卻不必改變主題。這就叫提前規劃！
- 針對介面編程，不針對實現編程
主題與觀察者都是用介面；觀察者利用主題的介面向主題註冊，而主題利用觀察者介面通知觀察者。這樣可以讓兩者之間運作正常，又同時具有松耦合的優點
- 多用組合，少用繼承
觀察者模式利用“組合”將許多觀察者組合進主題中。對象之間的這種關係不是通過繼承產生的，而是在運行時利用組合的方式而產生的。
至此，小編就學完了觀察者模式。相比較於書本，小編把觀察者模式的其中一些更好的概念理解縮減了，只單獨舉了一個報社訂閱報紙的例子來做進一步的解釋。以及模式中的“推”和“拉”是如何引出而來的，也沒有細說，在這節里把推和拉的特點進行了描述，並給出了一點拙見。
有留言給小編說圖的來源，以及是否需要有畫圖的能力。我把我在知識星球里的回答放出來，只是自己的一點感悟，如有不對的地方，可以留言給小編修正。『設計模式歸根到底還是需要一個思想，畫UML圖是為了更加深刻理解軟體工程中的知識。優秀的寫代碼的程式員不一定能畫好UML圖，能畫好UML的一定是個優秀的程式員（我是這麼理解的），很多公司都不需要畫圖，因為只要實現功能即可，這個能力，需要自己平時培養的。我畫UML圖也不太好，還停留在大學老師教育的階段，所以跟著這個學習，畫圖理解能力還提升了，也是另一種收穫吧。類圖、時序圖、用例圖都是比較重要的，掌握了能加深對軟體工程的理解』
觀察者模式就到這裡為止了。下一模式是裝飾者模式，就如開頭所說，小編會用心分塊，力爭短小精悍，讓各位的碎片化時間得到更充分的利用。
推薦閱讀
GitHub地址 HeadFirstDesign
