淺談設計模式<最通俗易懂的講解>

1、什麼是設計模式

設計模式是一套被反覆使用、多數人知曉的、通過分類編寫的、代碼設計經驗的總結。使用設計模式是爲了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。毫無疑問，設計模式使代碼編程真正工程化，設計模式是軟件工程的基石，如同大廈的一塊塊磚頭同樣。項目中合理的運用設計模式能夠完美的解決不少問題，每種模式都有響應的原理與之對應，每個模式描述了一個在咱們周圍不斷重複發生的問題，以及該問題的核心解決方案，這也是它能被普遍應用的緣由。

2、設計模式的三大分類及關鍵點

一、建立型模式：對象實例化的模式，建立型模式用於解耦對象的實例化過程。

1. 單例模式：某個類智能有一個實例，提供一個全局的訪問點。
2. 工廠模式：一個工廠類根據傳入的參量決定建立出哪種產品類的實例。
3. 抽象工廠模式：建立相關或依賴對象的家族，而無需明確指定具體類。
4. 建造者模式：封裝一個複雜對象的建立過程，並能夠按步驟構造。
5. 原型模式：經過複製現有的實例來建立新的實例。

二、結構型模式：把類或對象結合在一塊兒造成一個更大的結構。

1. 裝飾器模式：動態的給對象添加新的功能。
2. 代理模式：爲其它對象提供一個代理以便控制這個對象的訪問。
3. 橋接模式：將抽象部分和它的實現部分分離，使它們均可以獨立的變化。
4. 適配器模式：將一個類的方法接口轉換成客戶但願的另外一個接口。
5. 組合模式：將對象組合成樹形結構以表示「部分-總體」的層次結構。
6. 外觀模式：對外提供一個統一的方法，來訪問子系統中的一羣接口。
7. 享元模式：經過共享技術來有效的支持大量細粒度的對象。

三、行爲型模式：類和對象如何交互，及劃分責任和算法。

1. 策略模式：定義一系列算法，把他們封裝起來，而且使它們能夠相互替換。
2. 模板模式：定義一個算法結構，而將一些步驟延遲到子類實現。
3. 命令模式：將命令請求封裝爲一個對象，使得能夠用不一樣的請求來進行參數化。
4. 迭代器模式：一種遍歷訪問聚合對象中各個元素的方法，不暴露該對象的內部結構。
5. 觀察者模式：對象間的一對多的依賴關係。
6. 仲裁者模式：用一箇中介對象來封裝一系列的對象交互。
7. 備忘錄模式：在不破壞封裝的前提下，保持對象的內部狀態。
8. 解釋器模式：給定一個語言，定義它的文法的一種表示，並定義一個解釋器。
9. 狀態模式：容許一個對象在其對象內部狀態改變時改變它的行爲。
10. 責任鏈模式：將請求的發送者和接收者解耦，使的多個對象都有處理這個請求的機會。
11. 訪問者模式：不改變數據結構的前提下，增長做用於一組對象元素的新功能。

3、設計模式的幾種原則

一、開閉原則

（1）對於擴展是開放的（Open for extension）。這意味着模塊的行爲是能夠擴展的。當應用的需求改變時，咱們能夠對模塊進行擴展，使其具備知足那些改變的新行爲。也就是說，咱們能夠改變模塊的功能。

（2）對於修改是關閉的（Closed for modification）。對模塊行爲進行擴展時，沒必要改動模塊的源代碼或者二進制代碼。模塊的二進制可執行版本，不管是可連接的庫、DLL或者.EXE文件，都無需改動。

二、裏式代換原則

任何基類能夠出現的地方，子類必定能夠出現。里氏代換原則是繼承複用的基石，只有當衍生類能夠替換基類，軟件單位的功能不受影響時，基類才能真正的被複用，而衍生類也可以在基類的基礎上增長新的行爲。里氏代換原則是對開閉原則的補充。實現開閉原則的關鍵步驟就是抽象化。而基類與子類的繼承關係就是抽象化的具體實現，因此里氏代換原則是對實現抽象化的具體步驟的規範。

三、依賴倒轉原則

依賴倒轉原則是程序要依賴於抽象接口，不要依賴於具體實現。簡單的說就是要求對抽象進行編程，不要對實現進行編程，這樣就下降了客戶與實現模塊間的耦合。

四、接口隔離原則

客戶端不該該依賴它不須要的接口，一個類對另外一個類的依賴應該創建在最小的接口上。

五、迪米特法則

迪米特法則又叫作最少知識原則，就是說一個對象應當對其它對象又儘量少的瞭解，不和陌生人說話。

六、合成複用原則

合成複用原則要求在軟件複用時，要儘可能先使用組合或者聚合等關聯關係來實現，其次才考慮使用繼承關係來實現。若是要使用繼承關係，則必須嚴格遵循里氏替換原則。合成複用原則同里氏替換原則相輔相成的，二者都是開閉原則的具體實現規範。

4、設計模式關係

5、設計模式感想

一共有23種設計模式，能夠說都是爲了提升代碼的可讀性、可擴展性、可複用性、類的可替換性、組件化、可移植性等等特性。經過接口、抽象類、繼承、實現、委託、抽象、面向接口編程、多態、重載、重寫等方式使得代碼的這些特性得以彰顯，能夠說只有深入的理解了這些概念背後的哲學思想才能更好的理解設計模式。在設計模式中有不少思想，好比可使用委託的不要使用繼承、開閉原則，面向擴展開放，面向修改關閉，裏式代換原則，父類必定能被子類代替並使用，反置則否則，面向接口編程，功能層次和實現層次分離（橋接模式）、高內聚低耦合等思想，這些思想都是寶貴的，正是由於這樣的思想的存在才使得代碼的更新換代的時候可以儘量少的甚至不用修改以前的代碼，直接加入新的內容。提升軟件的開發週期，便於維護和升級，便於查找和糾錯，易於擴展和使用。

一樣的設計模式主要分爲三大類，建立型、行爲型、結構型。咱們能夠簡單的這樣分類，只不過這樣的分相似乎並不許確，不能一語道出全部的本質，設計模式是相互關聯的，有的設計模式內部實際上是使用了別的設計模式做爲支撐的，可是大致上這樣的一種劃分便於咱們去記憶，僅此而已。

仔細的回顧一下咱們前面學習的設計模式，看看咱們能想到多少，從迭代器開始，咱們將類中數據結構的遍歷和類的功能實現分離出來，本質上使用了工廠模式。其次咱們學習了適配器模式，它將不一樣的接口進行適配，從而便於版本的兼容性以及其餘功能，而後咱們學習了模板方法，使用模板面向抽象編程，便於新的子類的實現和管理；以後學習了工廠模式，其實借用了模板模式來建立產品，是一種很是重要用處很廣的一種方法；而後咱們學習了單例模式，有懶漢式、餓漢式等，生成關於某個類全局惟一的對象，注意多線程的影響；以後是原型模式，用來複制複雜的對象，使用了clone方法，而後是builder模式，用一個新的類對已有的抽象接口進行整合和編程，從而構建出咱們想要的東西；而後是抽象工廠模式，使用了工廠模式，組合模式等模式，面向抽象編程，將抽象零件組裝成抽象產品，便於具體工廠的建立，提升了代碼的組件化和複用性；而後是橋接模式，將類的功能層次和實現層次分割開來，便於對應的擴展和使用；而後是策略模式，能夠總體的替換策略，使用也很普遍；而後是組合模式，保證了同根同源，經過委託添加本身構成遞歸，樹形結構，將具備樹形特色的對象組合起來；而後是裝飾器模式，和組合模式的結構相似，一樣是遞歸結構，從而能夠不斷的裝飾，增長新的功能，很好用；接着是visitor訪問者模式，經過在類外訪問類中的數據結構從而獲得想要的結果，便於程序的可擴展性和組件化；接着是責任鏈模式，推卸責任，根據問題的大小來考慮本身釋放處理，本質是鏈表，便於職責分明；而後是外觀模式，經過整合各個類之間的調用關係，組建成了統一的接口(API)，便於外部類的調用；接着是仲裁者模式，將不少類之間互相關聯的關係交給仲裁者處理，省去了各個類之間的嵌套和調動，有利於高內聚和低耦合，思路清晰，便於擴展；而後是觀察者模式，經過互相委託從而可以在被觀察的類發生改變的時候獲得相應的改變的信息而且處理；而後是備忘錄模式，經過在某一時刻的狀態保存下來，便於恢復，在遊戲中使用的比較多；而後是狀態模式，將狀態當作類，從而職責分明，解除了不少繁瑣的if和else這些分支邏輯，便於擴展；而後是享元模式，輕量級對象，經過共用不變對象來實現；而後是代理模式，懶加載真正的服務器，加快訪問速度，代理是幫助服務器代理的；而後是命令模式，將命令當作類，經過保存一些列命令，從而可以隨時執行這些命令，須要清除命令的本質就是一些操做和數據；最後是解釋器模式，利用編程原理的方法，來更高層次的封裝代碼，將本身開發的java代碼當作編譯系統，從而不用改變java代碼只修改更高語言層次的代碼就能實現不一樣的功能。