一句話的事兒，Head first 設計模式

head first 設計模式，是比較有趣的一本設計模式的書。

在學校裏看書和在工做時看書，意義是不同的。在學校時是爲讀書而讀書，咱們能夠從0到1，咱們有的是時間。可是工做後就不同。

我以爲這時的書更像是打通本身任督二脈的武功祕訣。在平時工做中，雜七雜八地學了一些東西，可是卻不能融會貫通。因此還須要經過書來釐清你的思路。這是寫本文的出發點，也是個人碎碎念！

看完該書後，轉換成本身的語言，再表達出來，可能有錯（那是必定的），可是，有總比沒有好。若是有同窗可以從中獲得些啓發，也算是本身的一種幸運吧！

我竟試圖以一句話來描述一個設計模式！

1. 策略模式！

   將統一的東西做爲基類，可變的東西行爲獨立出來，在基類中經過變量進行引用，經過委託變量的方式，使用setter方法將委託變量改變，使其具備行爲可變性。面向接口編程，而非面向類編程。其好處是，用一樣的接口，經過不一樣行爲類的傳入產生不一樣的效果，便以改變行爲變得容易。

2. 觀察者模式！

   相似於發佈-訂閱模式。存在註冊服務，通知的過程。其實現方式能夠理解爲，註冊服務時，將觀察者加入到隊列當中，當主題發生變動時，由主題主動依次從觀察者隊列中依次調用，從而達到通知主動推送的做用。其好處是，觀察者隨時註冊觀察能夠實時收到消息，而被觀察者對此一無所知，從而在達到通知的同時也解藕了。

3. 裝飾者模式！

   以某對象爲主要對象，生成後，將其傳入裝飾者構造函數中，通過裝飾後，再行輸出的模式。該模式，能夠許多散亂的方法獨立組裝出來，而不會影響其餘變化，該模式是經過繼承來實現的。典型的裝飾者模式運用，java io 類的繼承，有多個主類，及多個裝飾類，從而方便用戶操做想要的方法。其好處是，在大方向不變的狀況下，能夠反覆更改主要的行爲結果，對於一些附加類的變化，能夠很方便地經過該模式進行數據再加工。

4. 工廠模式！

   分爲簡單工廠模式-工廠模式-抽象工廠模式。所謂工廠模式，便是將須要的產品和工廠結合在一塊兒，從而獲得一個具體須要的產品的一個過程，而無需知道這個產品具體是由誰生產的。工廠模式很好的複用了多個產品的變化性，避免了在各個類中進行各自實例化從而致使類的散亂問題。或者從另外一個角度來講，工廠只是某段複用性很高的代碼的抽離而已。其好處是，統一把控了一些類的生成，避免了各個類散落在代碼各個角落，從而給後期升級維護帶來方便。

5. 單例模式！

   就是全局只有一個實例對象的訪問方式（單進程方式）。須要一個私有構造器，使外部沒法實例化他，須要一個靜態方法getinstance供外部訪問實例使用，屬於懶加載行爲。但應注意多線程併發問題，從而建立兩個instance，使用synchronized同步方法或者volatile同步本實例，從而解決併發問題，可是這會致使應用性能下降100倍的性能。當應用中大量使用單例，就得考慮是否合理了，由於適合單例的場景並不不少。其好處是，減小系統反覆建立一個類時的性能開銷及空間開銷，且能夠多處共享一些變量（若是須要的話）。

6. 命令模式！

   將請求看成對象傳遞給另外一對象，從而實現命令的執行方式。使請求與執行解藕開來，能夠很方便地實現命令集操做，或者宏操做及回放。可以輕鬆實現日誌隊列操做。其好處是，將命令請求和命令執行分開，通常請求都會很快完成，可是執行卻不必定，因爲請求與執行分開，因此可以輕鬆實現過後補償的動做。

7. 適配器者模式！

   即實現A接口轉換B接口的適配工做，如實現鏈接三角插座與兩腳插頭鏈接工做，適配器的意義在於不用改變或不能改變現有接口的同時，將新的接口接入現有環境，意義重大。其實現爲，適配器繼承目標接口，並傳入被適配接口，將被適配接口的邏輯轉換成目標接口的表述。能夠繼承多個接口實現雙向轉換。其好處是，不對現有代碼進行改動的狀況下接入新廠商的東西，適應原有方式。

8. 外觀模式！

   外觀模式的意圖在於提供簡化的接口操做，同時，也不改變原有接口。其實現是一種類的包裝簡化。其遵循一個設計原則，只與最親密的人交談。其好處是，將原有複雜多變的接口轉化爲少且實用的幾個接口，使外部調用時，只作最簡單的事。

9. 模板方法模式！

   在一個父類接口中定義一個算法骨架或者操做流程，並將一個子類特有的方法以抽象方法的方式暴露出來，使在運行時使用父類的操做流程調用子類的特有方法的方式。該模式能夠省去許多機械代碼，使子類只關注本身特有的部分。本模式中，還有一個平凡而重要的概念，鉤子hook，鉤子在java中表現出來就是，一個只有空的方法或者默認實現的方法，子類只要對該方法進行覆蓋，就能夠觸發鉤子，從而實現開關控制和本身的意圖。由於是高層調用低層，因此存在有些操做的不明顯，若是低層又調用高層的話，將很難搞清楚設計，所以應遵循一個原則，好萊塢原則，只有父類調用子類，子類不得調用父類，所以若是想知道框架中爲何要讓你必須實現某個方法時，只需到父類中查看其調用一下便知，但不得私自調用父類方法。依賴倒置原則和這有點像。其好處是，將複雜流程封裝起來，只提供可變的方法讓子類重寫，從而在父類調用，減小許多重複的代碼。

10. 迭代器模式！

    也就是實現像iterator 接口同樣功能的方式，使對象可以不關注內部實現的狀況下遍歷元素。目前對咱們來講，應該是沒什麼意義了，由於相似於for in 的語法，已經徹底可以達到此類效果，該模式我的感受沒多大意義。其好處，就是爲了方便使用的地方可以遍歷出內部結構。

11. 組合模式！

    即將多個接口具備的方法，組合在一塊兒變爲一個更大的接口，讓操做者無需關注各種的差別，只管調用相同接口便可，可是對於有些子類沒有的方法則須要拋出異常，以使外部進行捕獲。使用場景得細細思量一番才行。這個功能，在gui編程時最明顯，當你拖動幾個系統提供的組件，在頁面上組合出新的結構時，就是利用了組合模式了。

12. 狀態模式！

    與策略模式相似。其做用是控制外部操做在內部的狀態流轉，並沒有需讓外部知曉，其操做實際上是將一系列的if else解放出來，使邏輯更清晰。其實現爲封閉整個流程的全部狀態，在用戶操做某一狀態後，該狀態只會作本身的事，並將狀態轉換到下一狀態，用戶進行下一操做時，內部已改變，可是對類內部來講，操做的還是單一狀態，所以邏輯清晰。可是該模式會產生大量狀態類，增長大量代碼，且需抽象出良好的狀態，比較考驗技術水平。其做用是，便邏輯更清晰，也更容易擴展。

13. 代理模式！

    即訪問對象不經過直接訪問的方式，而是去訪問代理讓代理去跟具體對象溝通，溝通好後將結果返回給訪問者，這裏通常會涉及到rmi遠程調用，代理模式減少了系統的複雜度（至少到調用者是的）。虛擬代理，緩存代理，同步代理，防火牆代理，寫入時複製代理。代理模式在現實中用的是很是普遍的，他爲咱們屏蔽許多複雜細節，由框架提供的代理，使咱們操做方便的同時，也讓咱們變得傻瓜。

14. 複合模式！

    即組合混合使用了多個模式的模式，該模式準確說不算是模式，可是也在框架中體現的最多的模式，如著名的mvc。組合策略，適配器，觀察者，裝飾器，組合模式，工廠等等。其好處是，在基礎模式的基礎上，再封裝出另外一實用模式，解決更具體的應用場景問題。

16.更多！

模式是某種情境下針對某種問題的某種解決方案。其餘模式，訪問者模式，中介模式，原型模式，橋接模式，責任鏈模式，。反模式，即很差的模式，表面看起來好，實際用以後會有大坑。

 

來源：等你歸去來
    連接：http://www.cnblogs.com/yougewe/p/8240977.html

更多幹貨領取可關注公衆號後回覆「乾貨」便可免費領取海量乾貨