23種設計模式彙總整理

 

 

一.設計模式：
模式是一種問題的解決思路，它已經適用於一個實踐環境。而且能夠適用於其餘環境。
做用：設計的重用；
爲設計提供共同的詞彙，每一個模式名就是一個設計詞彙，其概念使程序員方便交流；
在開發文檔中採用模式可讓其餘人更容易理解你的見解。
分類：根據目的的準則
1.建立型：與對象的建立有關
2.結構性：處理類或對象之間的組合
3.行爲性：描述類或對象如何交互及其如何分配職責。

二.設計模式的六大原則：

總原則－開閉原則

對擴展開放，對修改封閉。在程序須要進行拓展的時候，不能去修改原有的代碼，而是要擴展原有代碼，實現一個熱插拔的效果。因此一句話歸納就是：爲了使程序的擴展性好，易於維護和升級。

想要達到這樣的效果，咱們須要使用接口和抽象類等，後面的具體設計中咱們會提到這點。

 

一、單一職責原則

不要存在多於一個致使類變動的緣由，也就是說每一個類應該實現單一的職責，不然就應該把類拆分。

 

二、里氏替換原則（Liskov Substitution Principle）

任何基類能夠出現的地方，子類必定能夠出現。里氏替換原則是繼承複用的基石，只有當衍生類能夠替換基類，軟件單位的功能不受到影響時，基類才能真正被複用，而衍生類也可以在基類的基礎上增長新的行爲。

里氏代換原則是對「開-閉」原則的補充。實現「開閉」原則的關鍵步驟就是抽象化。而基類與子類的繼承關係就是抽象化的具體實現，因此里氏代換原則是對實現抽象化的具體步驟的規範。里氏替換原則中，子類對父類的方法儘可能不要重寫和重載。由於父類表明了定義好的結構，經過這個規範的接口與外界交互，子類不該該隨便破壞它。

 

三、依賴倒轉原則（Dependence Inversion Principle）

面向接口編程，依賴於抽象而不依賴於具體。寫代碼時用到具體類時，不與具體類交互，而與具體類的上層接口交互。

 

四、接口隔離原則（Interface Segregation Principle）

每一個接口中不存在子類用不到卻必須實現的方法，若是否則，就要將接口拆分。使用多個隔離的接口，比使用單個接口（多個接口方法集合到一個的接口）要好。

 

五、迪米特法則（最少知道原則）（Demeter Principle）

一個類對本身依賴的類知道的越少越好。不管被依賴的類多麼複雜，都應該將邏輯封裝在方法的內部，經過public方法提供給外部。這樣當被依賴的類變化時，才能最小的影響該類。

最少知道原則的另外一個表達方式是：只與直接的朋友通訊。類之間只要有耦合關係，就叫朋友關係。耦合分爲依賴、關聯、聚合、組合等。咱們稱出現爲成員變量、方法參數、方法返回值中的類爲直接朋友。局部變量、臨時變量則不是直接的朋友。咱們要求陌生的類不要做爲局部變量出如今類中。

 

六、合成複用原則（Composite Reuse Principle）

儘可能首先使用合成/聚合的方式，而不是使用繼承。

   

以前已經陸續整理了9種設計模式，連接以下，接下來一段時間陸續把剩餘的過一遍，整理出來，理解設計模式仍是很重要的。

建立型模式：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式

結構型模式：適配器模式、裝飾者模式、代理模式、外觀模式、橋接模式、組合模式、享元模式

行爲型模式：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式

還有兩類：併發型模式和線程池模式。

 

-------2017年8月31日更新----------------

設計模式須要幾個階段的學習， 沒有大量項目經驗的時候學習，可能只是瞭解， 當有了一些項目場景的時候，纔會深入體會到其中的奧妙。

 

上面文章有些在寫的時候，「借鑑」甚至「抄襲」了不少其餘博主的文章，主要也是當時本身理解的不夠深入，須要藉助現有的場景去理解，接下來會抽時間梳理一下設計模式的東西，整理一遍，但願能幫到你們。

 

三.設計模式分爲三大類：

建立型模式，共5種： 單例模式、工廠方法模式、抽象工廠模式、 建造者模式、原型模式。

結構型模式，共7種：  代理模式、橋接模式、 適配器模式、裝飾器模式、  外觀模式、組合模式、享元模式。

行爲型模式，共11種： 觀察者模式、模板方法模式、策略模式、責任鏈模式、 迭代子模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。

其實還有兩類：併發型模式和線程池模式。

 

=====-------建立型模式5種

　　一、單例模式：確保某一個類只有一個實例，並且自行實例化 並 提供一個訪問它的全局控制點。 單例模式只應在有真正的「單一實例」的需求時纔可以使用。

　　二、工廠方法模式：   

   　定義一個建立對象的接口，讓子類決定實例化哪一個類。當遇到須要根據某個前提條件建立不一樣的類實現時，會使用工廠模式。

    　核心工廠類再也不負責全部產品的建立，而是將具體建立的工做交給子類去作，成爲一個抽象工廠角色，僅負責給出具體工廠類必須實現的接口，而不接觸哪個產品類應當被實例化這種細節。 

　　三、工廠模式：

        提供一個建立一系列相關或相互依賴對象的接口，而無需指定它們具體的類；

        客戶類和工廠類分開。消費者任什麼時候候須要某種產品，只需向工廠請求便可。消費者無須修改就能夠接納新產品。

        缺點是當產品修改時，工廠類也要作相應的修改。如：如何建立及如何向客戶端提供。 

　　四、建造模式：將產品的內部表象和產品的生成過程分割開來，從而使一個建造過程生成具備不一樣的內部表象的產品對象。建造模式使得產品內部表象能夠獨立的變化，客戶沒必要知道產品內部組成的細節。 建造模式能夠強制實行一種分步驟進行的建造過程。 

　　五、原始模型模式：經過給出一個原型對象來指明所要建立的對象的類型，而後用複製這個原型對象的方法建立出更多同類型的對象。原始模型模式容許動態的增長或減小產品類，產品類不須要非得有任何事先肯定的等級結構，原始模型模式適用於任何的等級結構。缺點是每個類都必須配備一個克隆方法。 

　　------- 結構型模式7種

　　 六、代理模式：代理模式給某一個對象提供一個代理對象，並由代理對象控制對源對象的引用。代理就是一我的或一個機構表明另外一我的或者一個機構採起行動。某些狀況下，客戶不想或者不可以直接引用一個對象，代理對象能夠在客戶和目標對象直接起到中介的做用。客戶端分辨不出代理主題對象與真實主題對象。代理模式能夠並不知道真正的被代理對象，而僅僅持有一個被代理對象的接口，這時候代理對象不可以建立被代理對象，被代理對象必須有系統的其餘角色代爲建立並傳入。

--代理：Proxy.
爲其餘對象提供一種代理以控制對這個對象的訪問。
好比：在用戶登陸時候，真正的登陸類和代理登陸類都實現Login接口，不一樣的是Proxy類中方法增長了用戶是否合法的判斷，只有合法時纔去調用真正登陸類的login方法，用戶訪問的實際上是Proxy中的login()。

 

　　七、橋樑(接)模式：將抽象化與實現化脫耦，使得兩者能夠獨立的變化，也就是說將他們之間的強關聯變成弱關聯，也就是指在一個軟件系統的抽象化和實現化之間使用組合/聚合關係而不是繼承關係，從而使二者能夠獨立的變化。 

　　八、適配器（變壓器）模式：把一個類的接口變換成客戶端所期待的另外一種接口，從而使本來因接口緣由不匹配而沒法一塊兒工做的兩個類可以一塊兒工做。適配類能夠根據參數返還一個合適的實例給客戶端。 

 　 九、裝飾模式：裝飾模式以對客戶端透明的方式擴展對象的功能，是繼承關係的一個替代方案，提供比繼承更多的靈活性。動態給一個對象增長功能，這些功能能夠再動態的撤消。增長由一些基本功能的排列組合而產生的很是大量的功能。 

 -- 動態的給一個對象添加一些額外的職責。

如java.io包，BufferedInputStream封裝了FileInputStream，他們都實現了InputStream接口，但BufferedInputStream實現了 readLine();

 

　十、門面模式：外部與一個子系統的通訊必須經過一個統一的門面對象進行。門面模式提供一個高層次的接口，使得子系統更易於使用。每個子系統只有一個門面類，並且此門面類只有一個實例，也就是說它是一個單例模式。但整個系統能夠有多個門面類。 

　 十一、合成模式：合成模式將對象組織到樹結構中，能夠用來描述總體與部分的關係。合成模式就是一個處理對象的樹結構的模式。合成模式把部分與總體的關係用樹結構表示出來。合成模式使得客戶端把一個個單獨的成分對象和由他們複合而成的合成對象同等看待。 

　十二、享元模式：FLYWEIGHT在拳擊比賽中指最輕量級。享元模式以共享的方式高效的支持大量的細粒度對象。享元模式能作到共享的關鍵是區份內蘊狀態和外蘊狀態。內蘊狀態存儲在享元內部，不會隨環境的改變而有所不一樣。外蘊狀態是隨環境的改變而改變的。外蘊狀態不能影響內蘊狀態，它們是相互獨立的。將能夠共享的狀態和不能夠共享的狀態從常規類中區分開來，將不能夠共享的狀態從類裏剔除出去。客戶端不能夠直接建立被共享的對象，而應當使用一個工廠對象負責建立被共享的對象。享元模式大幅度的下降內存中對象的數量。 

-------  行爲型模式共11種

      1三、觀察者模式：觀察者模式定義了一種一隊多的依賴關係，讓多個觀察者對象同時監聽某一個主題對象。這個主題對象在狀態上發生變化時，會通知全部觀察者對象，使他們可以自動更新本身。 

觀察者：定義了一種一對多的依賴關係，讓多個觀察者對象同時監聽某一主題對象，在它的狀態發生變化時，會通知全部的觀察者。

如：ServletContextListener,在application啓動時，會通知全部這個接口的實現類。

　  1四、模板方法模式：模板方法模式準備一個抽象類，將部分邏輯以具體方法以及具體構造子的形式實現，而後聲明一些抽象方法來迫使子類實現剩餘的邏輯。不一樣的子類能夠以不一樣的方式實現這些抽象方法，從而對剩餘的邏輯有不一樣的實現。先制定一個頂級邏輯框架，而將邏輯的細節留給具體的子類去實現。

 

模板方法模式：
定義一個操做中的算法骨架，而將一些步驟延遲到子類中。
優勢：1）提取公共部分代碼，易於維護 2）由父類控制，子類實現；
3）封裝不可變部分，擴展可變部分。

 

　  1五、策略模式：策略模式針對一組算法，將每個算法封裝到具備共同接口的獨立的類中，從而使得它們能夠相互替換。策略模式使得算法能夠在不影響到客戶端的狀況下發生變化。策略模式把行爲和環境分開。環境類負責維持和查詢行爲類，各類算法在具體的策略類中提供。因爲算法和環境獨立開來，算法的增減，修改都不會影響到環境和客戶端。

策略模式：定義了算法家族，分別封裝起來，讓它們之間能夠互相替換。

好比：Collections.sort（List list,Comparator com); 可經過實現多個Comparator接口來達到多種排序的目的。

　　1六、責任鏈模式：在責任鏈模式中，不少對象由每個對象對其下家的引用而接
　　起來造成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求。客戶並不知道鏈上的哪個對象最終處理這個請求，系統能夠在不影響客戶端的狀況下動態的從新組織鏈和分配責任。處理者有兩個選擇：承擔責任或者把責任推給下家。一個請求能夠最終不被任何接收端對象所接受。 

　　

     1七、訪問者模式：訪問者模式的目的是封裝一些施加於某種數據結構元素之上的操做。一旦這些操做須要修改的話，接受這個操做的數據結構能夠保持不變。訪問者模式適用於數據結構相對未定的系統，它把數據結構和做用於結構上的操做之間的耦合解脫開，使得操做集合能夠相對自由的演化。訪問者模式使得增長新的操做變的很容易，就是增長一個新的訪問者類。訪問者模式將有關的行爲集中到一個訪問者對象中，而不是分散到一個個的節點類中。當使用訪問者模式時，要將盡量多的對象瀏覽邏輯放在訪問者類中，而不是放到它的子類中。訪問者模式能夠跨過幾個類的等級結構訪問屬於不一樣的等級結構的成員類。

　　1七、命令模式：命令模式把一個請求或者操做封裝到一個對象中。命令模式把發出命令的責任和執行命令的責任分割開，委派給不一樣的對象。命令模式容許請求的一方和發送的一方獨立開來，使得請求的一方沒必要知道接收請求的一方的接口，更沒必要知道請求是怎麼被接收，以及操做是否執行，什麼時候被執行以及是怎麼被執行的。系統支持命令的撤消。 

　　1八、解釋器模式：給定一個語言後，解釋器模式能夠定義出其文法的一種表示，並同時提供一個解釋器。客戶端可使用這個解釋器來解釋這個語言中的句子。解釋器模式將描述怎樣在有了一個簡單的文法後，使用模式設計解釋這些語句。在解釋器模式裏面提到的語言是指任何解釋器對象可以解釋的任何組合。在解釋器模式中須要定義一個表明文法的命令類的等級結構，也就是一系列的組合規則。每個命令對象都有一個解釋方法，表明對命令對象的解釋。命令對象的等級結構中的對象的任何排列組合都是一個語言。 

　　1九、迭代子模式：迭代子模式能夠順序訪問一個彙集中的元素而沒必要暴露彙集的內部表象。多個對象聚在一塊兒造成的整體稱之爲彙集，彙集對象是可以包容一組對象的容器對象。迭代子模式將迭代邏輯封裝到一個獨立的子對象中，從而與彙集自己隔開。迭代子模式簡化了彙集的界面。每個彙集對象均可以有一個或一個以上的迭代子對象，每個迭代子的迭代狀態能夠是彼此獨立的。迭代算法能夠獨立於彙集角色變化。 

　　20、調停者模式：調停者模式包裝了一系列對象相互做用的方式，使得這些對象沒必要相互明顯做用。從而使他們能夠鬆散偶合。當某些對象之間的做用發生改變時，不會當即影響其餘的一些對象之間的做用。保證這些做用能夠彼此獨立的變化。調停者模式將多對多的相互做用轉化爲一對多的相互做用。調停者模式將對象的行爲和協做抽象化，把對象在小尺度的行爲上與其餘對象的相互做用分開處理。 

　　2一、備忘錄模式：備忘錄對象是一個用來存儲另一個對象內部狀態的快照的對象。備忘錄模式的用意是在不破壞封裝的條件下，將一個對象的狀態捉住，並外部化，存儲起來，從而能夠在未來合適的時候把這個對象還原到存儲起來的狀態。 

　　2二、狀態模式：狀態模式容許一個對象在其內部狀態改變的時候改變行爲。這個對象看上去象是改變了它的類同樣。狀態模式把所研究的對象的行爲包裝在不一樣的狀態對象裏，每個狀態對象都屬於一個抽象狀態類的一個子類。狀態模式的意圖是讓一個對象在其內部狀態改變的時候，其行爲也隨之改變。狀態模式須要對每個系統可能取得的狀態創立一個狀態類的子類。當系統的狀態變化時，系統便改變所選的子類。