原則，故名思議則是本質的意思。所謂擒賊先擒王，研究設計模式自然要先瞭解設計原則，所有的模式都是在這些原則的基礎之上發展起來的，有的是側重一個，有的是多個都有所涉及。看完設計模式之後，我感覺到每個模式都有這些原則的影子，還滲透著面向對象的三大屬性，也覺得這些原則也都有相通之處，，正是有了他們才使我們由 ...
原則，故名思議則是本質的意思。所謂擒賊先擒王，研究設計模式自然要先瞭解設計原則，所有的模式都是在這些原則的基礎之上發展起來的，有的是側重一個，有的是多個都有所涉及。看完設計模式之後，我感覺到每個模式都有這些原則的影子，還滲透著面向對象的三大屬性，也覺得這些原則也都有相通之處，，正是有了他們才使我們由代碼工人轉為藝術家。下麵我來點評一下六大原則，望各位拍磚：
1、單一職責原則（Single Responsibility Principle，簡稱SRP）
單一職責原則，就一個類而言，應該僅有一個引起它變化的原因。如果一個類承擔的職責過多，就等於把這些職責耦合在一起，一個職責的變化可能會消弱或者一直這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。而軟體設計真正要做的許多內容，就是發現職責，並把這些職責相互分離。
一句話點評：高內聚低耦合的絕佳體現，不要亂拉關係，獨善其身挺好。
2、 開放--封閉原則（The Open-Closed Principle,簡稱OCP）
開放--封閉原則，是說軟體實體（類、模塊、函數等等）應該可以擴展，但是不可以修改。即對於擴展是開放的，對於更改是封閉的。 我們不可能做到未卜先知，在設計的時候儘可能讓一個類足夠好，設計好了就不要去修改了；不能完全封閉的情況下，當發生變化時，我們就創建抽象來隔離以後發生的同類變化。
一句話點評：開放擴展，封閉更改，開合有度是一門藝術。
http://hovertree.com/h/bjaf/7cuf5s2n.htm
3、依賴倒轉原則（Dependence Inversion Principle ）
依賴倒轉原則，指高層模塊不應該依賴低層模塊，兩個都應該依賴抽象；抽象不應該依賴細節，細節應該依賴抽象。說白了就是要針對介面編程，不要對實現編程。舉個例子：電腦硬體中，如果記憶體壞了，那麼只需要換一個記憶體條就可以了，而不需要去換一個主板，在這裡記憶體是一個介面類，只要符合他的規格要求就行，無論是那一根。
一句話點評：搞建築時要做設計師，而不是磚瓦工，抽象的藍圖要靠具體的材料一點點實現。
4、里氏代換原則（Liskov Substitution Principle，簡稱LSP）
里氏代換原則，子類型必須能夠替換掉他們的父類型。在軟體裡面，把父類都替換成其子類，程式的行為不會發生變化。正是由於子類型的可替換性才使得使用父類型的模塊在無需修改的情況下就可以擴展。
一句話點評：長輩給了你繼承的權利就一定要做贍養的義務，把長輩的職責都要承擔起來。
5、迪米特法則（Law of Demeter）
迪米特法則，如果兩個類不必彼此直接通信，那麼這兩個類就不應當發生直接的相互作用。如果其中一個類需要調用另一個類的某一個方法時，可以通過第三者轉發這個調用。類之間的耦合越弱，就越有利於復用，一個處在弱耦合的類被修改，不會對有關係的類造成波及。 主要是強調了類之間的松耦合。
一句話點評：不要和陌生人說話，若兩國交戰要儘量避免正面衝突，多派使者協商調度。
6、合成/聚合復用原則（Composition/Aggregation Principle]，簡稱CARP）
合成聚合復用原則，儘量使用合成/聚合，儘量不使用類繼承。合成聚合是“has a”的關係，而繼承是“is a”的關係。由於繼承是一中強耦合的結構，父類變，子類必變。所以不是“is a”關係，我們一般不要用繼承。優先使用合成聚合復用原則，有助於保持每個類的封裝，降低繼承的層次。
一句話點評：優生優育，不要盲目繁衍。
推薦：http://www.cnblogs.com/roucheng/p/sheji.html
