原則，故名思議則是本質的意思。所謂擒賊先擒王，研究設計模式自然要先了解設計原則，所有的模式都是在這些原則的基礎之上發展起來的，有的是側重一個，有的是多個都有所涉及。看完設計模式之後，我感覺到每個模式都有這些原則的影子，還滲透著面向物件的三大屬性，也覺得這些原則也都有相通之處，，正是有了他們才使我們由程式碼工人轉為藝術家。下面我來點評一下六大原則，望各位拍磚：

1、單一職責原則（Single Responsibility Principle，簡稱SRP）
      單一職責原則，就一個類而言，應該僅有一個引起它變化的原因。如果一個類承擔的職責過多，就等於把這些職責耦合在一起，一個職責的變化可能會消弱或者一直這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。而軟體設計真正要做的許多內容，就是發現職責，並把這些職責相互分離。

      一句話點評：高內聚低耦合的絕佳體現，不要亂拉關係，獨善其身挺好。

2、 開放--封閉原則（The Open-Closed Principle,簡稱OCP）
       開放--封閉原則，是說軟體實體（類、模組、函式等等）應該可以擴充套件，但是不可以修改。即對於擴充套件是開放的，對於更改是封閉的。 我們不可能做到未卜先知，在設計的時候儘可能讓一個類足夠好，設計好了就不要去修改了；不能完全封閉的情況下，當發生變化時，我們就建立抽象來隔離以後發生的同類變化。

      一句話點評：開放擴充套件，封閉更改，開合有度是一門藝術。

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

     一句話點評：搞建築時要做設計師，而不是磚瓦工，抽象的藍圖要靠具體的材料一點點實現。

4、里氏代換原則（Liskov Substitution Principle，簡稱LSP）
     里氏代換原則，子型別必須能夠替換掉他們的父型別。在軟體裡面，把父類都替換成其子類，程式的行為不會發生變化。正是由於子型別的可替換性才使得使用父型別的模組在無需修改的情況下就可以擴充套件。

     一句話點評：長輩給了你繼承的權利就一定要做贍養的義務，把長輩的職責都要承擔起來。

5、迪米特法則（Law of Demeter）
      迪米特法則，如果兩個類不必彼此直接通訊，那麼這兩個類就不應當發生直接的相互作用。如果其中一個類需要呼叫另一個類的某一個方法時，可以通過第三者轉發這個呼叫。類之間的耦合越弱，就越有利於複用，一個處在弱耦合的類被修改，不會對有關係的類造成波及。 主要是強調了類之間的鬆耦合。

     一句話點評：不要和陌生人說話，若兩國交戰要儘量避免正面衝突，多派使者協商排程。

6、合成/聚合複用原則（Composition/Aggregation Principle]，簡稱CARP）
     合成聚合複用原則，儘量使用合成/聚合，儘量不使用類繼承。合成聚合是“has  a”的關係，而繼承是“is  a”的關係。由於繼承是一中強耦合的結構，父類變，子類必變。所以不是“is  a”關係，我們一般不要用繼承。優先使用合成聚合複用原則，有助於保持每個類的封裝，降低繼承的層次。
     一句話點評：優生優育，不要盲目繁衍。