一.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） 

三.總結