一句話評論設計模式六大原則

原文連結：http://www.cnblogs.com/lancidie/archive/2012/02/03/2337168.html

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

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”關系，我們一般不要用繼承。優先使用合成聚合複用原則，有助于保持每個類的封裝，降低繼承的層次。

     一句話點評：優生優育，不要盲目繁衍。