設計模式解密（23） - 總結篇

索引目錄&&傳送門：

整體來講設計模式分爲三大類：

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

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

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

總結結構圖

 這裏可能看不清楚：大圖連接 （提示：放大查看）

一、設計模式的六大原則

一、開閉原則（Open Close Principle）

　　開閉原則的意思是：對擴展開放，對修改關閉。在程序須要進行拓展的時候，不能去修改原有的代碼，實現一個熱插拔的效果。簡言之，是爲了使程序的擴展性好，易於維護和升級。想要達到這樣的效果，咱們須要使用接口和抽象類，後面的具體設計中咱們會提到這點。

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

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

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

　　這個原則是開閉原則的基礎，具體內容：針對對接口編程，依賴於抽象而不依賴於具體。

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

　　這個原則的意思是：使用多個隔離的接口，比使用單個接口要好。它還有另一個意思是：下降類之間的耦合度。因而可知，其實設計模式就是從大型軟件架構出發、便於升級和維護的軟件設計思想，它強調下降依賴，下降耦合。

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

　　最少知道原則是指：一個實體應當儘可能少地與其餘實體之間發生相互做用，使得系統功能模塊相對獨立。

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

　　合成複用原則是指：儘可能使用合成/聚合的方式，而不是使用繼承。

二、建立型模式（5種）

　　單例模式(Singleton)：保證一個類僅有一個實例，並提供一個訪問它的全局訪問點。

　　工廠方法(Factory Method)：定義一個建立對象的接口，讓其子類本身決定實例化哪個工廠類，工廠模式使其建立過程延遲到子類進行。

　　抽象工廠(Abstract Factory)：提供一個建立一系列相關或相互依賴對象的接口，而無需指定它們具體的類。

　　建造者模式(Builder)：將一個複雜對象的構建與它的表示分離，使得一樣的構建過程能夠建立不一樣的表示。

　　原型模式(Prototype)：用原型實例指定建立對象的種類，而且經過拷貝這些原型來建立新的對象。

三、結構型模式 （7種）

　　適配器模式(Adapter)：適配器模式把一個類的接口變換成客戶端所期待的另外一種接口，從而使本來因接口不匹配而沒法在一塊兒工做的兩個類可以在一塊兒工做。

　　裝飾模式(Decrator)：裝飾模式是在沒必要改變原類文件和使用繼承的狀況下，動態的擴展一個對象的功能。它是經過建立一個包裝對象，也就是裝飾來包裹真實的對象。

　　代理模式(Proxy)：爲其餘對象提供一種代理以控制對這個對象的訪問 ；

　　外觀模式(Facade)：爲子系統中的一組接口提供一個一致的界面，外觀模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。

　　橋接模式(Bridge)：將抽象部分與實現部分分離，使它們均可以獨立的變化。

　　組合模式(Composite)：容許你將對象組合成樹形結構來表現"總體-部分"層次結構。 組合能讓客戶以一致的方法處理個別對象以及組合對象。

　　享元模式(Flyweight)：運用共享技術有效地支持大量細粒度的對象。

四、行爲型模式（11種）

　　策略模式(Strategy)：定義一組算法，將每一個算法都封裝起來，而且使他們之間能夠互換。

　　模板方法(Template Method)：一個操做中算法的框架，而將一些步驟延遲到子類中，使得子類能夠不改變算法的結構便可重定義該算法中的某些特定步驟。

　　觀察者模式(Observer)：定義對象間的一種一對多的依賴關係，當一個對象的狀態發生改變時，全部依賴於它的對象都獲得通知並被自動更新。

　　迭代器模式(Iterator)：提供一種方法順序訪問一個聚合對象中各個元素, 而又無須暴露該對象的內部表示；

　　職責鏈模式(Chain of Responsibility)：避免請求發送者與接收者耦合在一塊兒，讓多個對象都有可能接收請求，將這些對象鏈接成一條鏈，而且沿着這條鏈傳遞請求，直到有對象處理它爲止。

　　命令模式(Command)：將一個請求封裝爲一個對象，從而使你能夠用不一樣的請求對客戶進行參數化，對請求排隊和記錄請求日誌，以及支持可撤銷的操做；

　　備忘錄模式(Memento)：在不破壞封裝性的前提下，捕獲一個對象的內部狀態，並在該對象以外保存這個狀態。這樣就能夠將該對象恢復到原先保存的狀態。

　　狀態模式(State)：容許對象在內部狀態改變時改變它的行爲, 對象看起來好像修改了它的類。

　　訪問者模式(Visitor)：表示一個做用於其對象結構中的各元素的操做，它使你能夠在不改變各元素類的前提下定義做用於這些元素的新操做。

       中介者模式(Mediator)：用一箇中介對象來封裝一系列的對象交互，中介者使各對象不須要顯示地相互引用。從而使其耦合鬆散，並且能夠獨立地改變它們之間的交互。

　　解釋器模式(Interpreter)：給定一個語言，定義它的文法表示，並定義一個解釋器，這個解釋器使用該標識來解釋語言中的句子。

 五、總結篇

 目的：爲了代碼的複用、容易理解和保證代碼的可靠性。最終要達成的效果是：可擴展性、可修改性、可替換性。

 設計模式四大階段：

　　一、沒學以前，什麼是設計模式，老聽別人說設計模式，感受好高大上，那它究竟是什麼鬼。這時咱們設計的代碼複用性不好、難以維護。

　　二、學了幾個模式後，感受很簡單，因而處處想着要用本身學過的模式，這樣就會形成濫用。最後感受還不如不用。

　　三、學徹底部模式時，感受不少模式太類似了，沒法很清晰的知道各模式之間的區別、聯繫，這時一臉懵逼，腦子一團亂麻。在使用時，分不清要使用那種模式。

　　四、模式已熟記於心，已忘其形，深知其意，達到無劍勝有劍的境界，恭喜你，萬劍歸宗已練成！！！

 PS：

　　在學習設計模式時，必定要理解模式的適用性。作到了解它的優勢、弊端！！！

　　設計模式非一日可成，須要咱們長期的實踐，多看框架的源碼，多研究，會對你有很大的幫助！！！

  

PS：源碼地址   https://github.com/JsonShare/DesignPattern/tree/master 

   

PS：原文地址  http://www.cnblogs.com/JsonShare/p/7110200.html