1. 單一職責原則（Single Responsibility Principle） 每一個類應該專註於做一件事情。 每一個職責都是變化的一個軸線，如果一個類有一個以上的職責，這些職責就耦合在了一起。這會導致脆弱的設計。當一個職責發生變化時，可能會影響其它的職責。另外，多個職責耦合在一起，會影響復用 ...
1. 單一職責原則（Single Responsibility Principle）
每一個類應該專註於做一件事情。
每一個職責都是變化的一個軸線，如果一個類有一個以上的職責，這些職責就耦合在了一起。這會導致脆弱的設計。當一個職責發生變化時，可能會影響其它的職責。另外，多個職責耦合在一起，會影響復用性。例如：要實現邏輯和界面的分離。需要說明的一點是單一職責原則不只是面向對象編程思想所特有的，只要是模塊化的程式設計，都需要遵循這一重要原則。
2. 里氏替換原則（Liskov Substitution Principle）
超類存在的地方，子類是可以替換的。
子類型必須能夠替換掉它們的父類型。註意這裡的能夠兩字。有人也戲稱老鼠的兒子會打洞原則。
所有引用父類的地方必須能透明地使用其子類的對象。子類可以擴展父類的功能，但不能改變父類原有的功能，即：子類可以實現父類的抽象方法，子類也中可以增加自己特有的方法，但不能覆蓋父類的非抽象方法。當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬鬆。當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。
3. 依賴倒置原則（Dependence Inversion Principle）
實現儘量依賴抽象，不依賴具體實現。
高層模塊不應該依賴低層模塊，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象。中心思想是面向介面編程
在實際編程中，我們一般需要做到如下3點：
1. 低層模塊儘量都要有抽象類或介面，或者兩者都有。
2. 變數的聲明類型儘量是抽象類或介面。
3. 使用繼承時遵循里氏替換原則。
採用依賴倒置原則尤其給多人合作開髮帶來了極大的便利，參與協作開發的人越多、項目越龐大，採用依賴導致原則的意義就越重大。
依賴倒置原則就是要我們面向介面編程，理解了面向介面編程，也就理解了依賴倒置。
4. 介面隔離原則（Interface Segregation Principle）
應當為客戶端提供儘可能小的單獨的介面，而不是提供大的總的介面。
客戶端不應該依賴它不需要的介面；一個類對另一個類的依賴應該建立在最小的介面上。
我們在代碼編寫過程中，運用介面隔離原則，一定要適度，介面設計的過大或過小都不好。對介面進行細化可以提高程式設計靈活性是不掙的事實，但是如果過小，則會造成介面數量過多，使設計複雜化。所以一定要適度。設計介面的時候，只有多花些時間去思考和籌劃，就能準確地實踐這一原則。
5. 迪米特法則（Law Of Demeter）
又叫最少知識原則，一個軟體實體應當儘可能少的與其他實體發生相互作用。
即：一個對象應該對其他對象保持最少的瞭解。如果兩個類不必彼此直接通信，那麼這兩個類就不應當發生直接的相互作用。如果其中一個類需要調用另一個類的某一個方法的話，可以通過第三者轉發這個調用。簡單定義為只與直接的朋友通信。首先來解釋一下什麼是直接的朋友：每個對象都會與其他對象有耦合關係，只要兩個對象之間有耦合關係，我們就說這兩個對象之間是朋友關係。耦合的方式很多，依賴、關聯、組合、聚合等。其中，我們稱出現成員變數、方法參數、方法返回值中的類為直接的朋友，而出現在局部變數中的類則不是直接的朋友。也就是說，陌生的類最好不要作為局部變數的形式出現在類的內部。
迪米特法則的初衷是降低類之間的耦合，由於每個類都減少了不必要的依賴，因此的確可以降低耦合關係。但是凡事都有度，雖然可以避免與非直接的類通信，但是要通信，必然會通過一個“中介”來發生聯繫。故過分的使用迪米特原則，會產生大量這樣的中介和傳遞類，導致系統複雜度變大。所以在採用迪米特法則時要反覆權衡，既做到結構清晰，又要高內聚低耦合。
6. 開閉原則（Open Close Principle）
面向擴展開放，面向修改關閉。
更通俗一點講，也就是：軟體系統中包含的各種組件，例如模塊（Modules）、類（Classes）以及功能（Functions）等等，應該在不修改現有代碼的基礎上，去擴展新功能。開閉原則中原有“開”，是指對於組件功能的擴展是開放的，是允許對其進行功能擴展的；開閉原則中“閉”，是指對於代碼的修改是封閉的，即不應該修改原有的代碼。
開閉原則具有理想主義的色彩，說的很抽象，它是面向對象設計的終極目標。其他幾條原則，則可以看做是開閉原則的實現。我們要用抽象構建框架，用實現擴展細節。
7. 組合/聚合復用原則（Composite/Aggregate Reuse Principle CARP）
儘量使用合成/聚合達到復用，儘量少用繼承。原則： 一個類中有另一個類的對象。
及儘量使用合成/聚合，儘量不要使用類繼承。換句話說，就是能用合成/聚合的地方，絕不用繼承。
為什麼要儘量使用合成/聚合而不使用類繼承？
1. 對象的繼承關係在編譯時就定義好了，所以無法在運行時改變從父類繼承的子類的實現
2. 子類的實現和它的父類有非常緊密的依賴關係，以至於父類實現中的任何變化必然會導致子類發生變化
3. 當你復用子類的時候，如果繼承下來的實現不適合解決新的問題，則父類必須重寫或者被其它更適合的類所替換，這種依賴關係限制了靈活性，並最終限制了復用性。
