[轉]設計模式--六大原則與三種類型

一.6大原則

1.單一職責原則（Single Responsibility Principle）

定義：就一個類而言，應該僅有一個引發它變化的緣由；

       若是一個類承擔的職責過多，就等於把這些職責耦合在一塊兒，一個職責變化可能會消弱或者抑制這個類完成其餘職責的能力。這種耦合會致使脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞；

　　T負責兩個不一樣的職責：職責P1，職責P2。當因爲職責P1需求發生改變而須要修改類T時，有可能會致使本來運行正常的職責P2功能發生故障。也就是說職責P1和P2被耦合在了一塊兒。

　　單一職責比較容易理解，可是在實際設計過程當中容易發生職責擴散：由於某種緣由，某一職責被分化爲顆粒度更細的多個職責了。

　　解決辦法：遵照單一職責原則，將不一樣的職責封裝到不一樣的類或模塊中。

2.里氏替換原則（LiskovSubstitution Principle）

定義：子類型必須可以替換掉它們的父類型；

　　一個軟件實體若是使用的是一個父類的話，那麼必定適用於其子類，並且它察覺不出父類對象和子類對象的區別。也就是說，在軟件裏面，把父類都替換成它的子類，程序的行爲沒有變化；

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

　　在進行設計的時候，咱們儘可能從抽象類繼承，而不是從具體類繼承。若是從繼承等級樹來看，全部葉子節點應當是具體類，而全部的樹枝節點應當是抽象類或者接口。

3.依賴倒置原則（DependenceInversion Principle）

定義：

　　A.高層模塊不該該依賴低層模塊。兩個都應該依賴抽象；

　　B.抽象不該該依賴細節，細節應該依賴抽象；（針對接口編程，而不是針對實現；）

　　

　　面向過程的開發，上層調用下層，上層依賴於下層，當下層劇烈變更時上層也要跟着變更，這就會致使模塊的複用性下降並且大大提升了開發的成本。依賴倒轉很好的解決了這個問題；

4.合成/聚合原則（Composite/Aggregate Reuse Principle）

定義：儘可能使用合成/聚合，儘可能不要使用類繼承；

　　優先使用對象的合成/聚合將有助於你保持每一個類被封裝，並被集中在單個任務上。這樣類和類繼承層次會保持較小規模，而且不太可能增加爲不可控制的龐然大物；

　　

　　爲何儘可能不要使用類繼承而使用合成/聚合？

　　　　對象的繼承關係在編譯時就定義好了，因此沒法在運行時改變從父類繼承的子類的實現。

　　　　子類的實現和它的父類有很是緊密的依賴關係，以致於父類實現中的任何變化必然會致使子類發生變化。

　　　　當你複用子類的時候，若是繼承下來的實現不適合解決新的問題，則父類必須重寫或者被其它更適合的類所替換。

　　　　這種依賴關係限制了靈活性，並最終限制了複用性。

5.迪米特法則（Law Of Demeter）

定義：若是兩個類沒必要彼此直接通訊，那麼這兩個類就不該當發生直接的相互做用，若是其中一個類須要調用另外一個類的某一個方法的話，能夠經過第三者轉發這個調用；

　　迪米特根本思想是：類之間的鬆耦合；

　　類之間的耦合越弱，越有利於複用，一個處於弱耦合的類被修改，不會對有關係的類形成波及。信息的隱藏促進了軟件的複用；

　　廣義的迪米特法則在類的設計上的體現：

　　　　優先考慮將一個類設置成不變類。

　　　　儘可能下降一個類的訪問權限。

　　　　謹慎使用Serializable。

　　　　儘可能下降成員的訪問權限。

6.開放-封閉原則（Open Closed Principle）

定義：軟件實體（類，模塊，函數等等）應該能夠擴展，可是不能夠修改；

　　對擴展開放，意味着有新的需求或變化時，能夠對現有代碼進行擴展，以適應新的狀況。

　　對修改封閉，意味着類一旦設計完成，就能夠獨立完成其工做，而不要對類進行任何修改。

　　這樣的設計，可以面對需求改變卻能夠保持相對穩定，從而使系統在第一個版本之後不斷推出新的版本；面對需求，對程序的改動是經過增長新的代碼進行的，而不是更改現有的代碼；

　　開放封閉原則，是最爲重要的設計原則，Liskov替換原則和合成/聚合複用原則爲開放封閉原則的實現提供保證。

二.3種類型

　　設計模式分爲那幾類，它們是怎麼區分的，每一種模式類型的特色，包含具體模式呢？

　　設計模式按照目的來分，能夠分爲建立型模式、結構型模式和行爲型模式。

1.建立型

　　建立型模式用來處理對象的建立過程，主要包含如下5種設計模式：

工廠方法模式（Factory Method Pattern）

抽象工廠模式（Abstract Factory Pattern）

建造者模式（Builder Pattern）

原型模式（Prototype Pattern）

單例模式（Singleton Pattern）

2.結構型

　　結構型模式用來處理類或者對象的組合，主要包含如下7種設計模式：

適配器模式（Adapter Pattern）

橋接模式（Bridge Pattern）

組合模式（Composite Pattern）

裝飾者模式（Decorator Pattern）

外觀模式（Facade Pattern）

享元模式（Flyweight Pattern）

代理模式（Proxy Pattern）

3.行爲型

　　行爲型模式用來對類或對象怎樣交互和怎樣分配職責進行描述，主要包含如下11種設計模式：

責任鏈模式（Chain of Responsibility Pattern）

命令模式（Command Pattern）

解釋器模式（Interpreter Pattern）

迭代器模式（Iterator Pattern）

中介者模式（Mediator Pattern）

備忘錄模式（Memento Pattern）

觀察者模式（Observer Pattern）

狀態模式（State Pattern）

策略模式（Strategy Pattern）

模板方法模式（Template Method Pattern）

訪問者模式（Visitor Pattern） 

三.總結

　　設計原則是實現代碼複用，增長可維護性。而設計模式就是實現了這些原則，達到了代碼複用和增長可維護行的目的。設計模式的重點仍是熟練理解理論知識的基礎上可以作大靈活的應用，讓設計出來的系統更加健壯，代碼更加優化。前期剛學習的時候，作到可以套用，隨着熟練程度的加深，達到無招勝有招，將各類模式融合的系統的實踐中。