1.單一職責原則

定義：就一個類而言，應該僅有一個引起它變化的原因。這句話的意思是說：我們不要讓一個類承擔過多的職責，如果一個類承擔的職責過多，就等于把這些職責全部耦合子一起。一個職責的變化可能會削弱活著抑制這個類完成其他的職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭到破環。比如我經常看到一些android開發在Activity中寫網絡數據處理邏輯，如果有listview列表的話也寫在activity類中，問他們為什么這樣寫除了好找代碼也沒啥理由了，如果把它們拆分大別的類中不是更好找，更清晰了嗎。如果acticity過于臃腫行數過多，顯然不是什么好事，如果列表adpater和網絡數據有變化，我們都要在這個activity來修改，就會導致這個activity的變化的原因太多，我們在版本維護的時候也會比較頭疼。也就嚴重違背了定義“就一個類而言。應該僅有一個引起它變化的原因”。

2.開放封閉原則

定義：類、模塊、函數等等等應該是可以拓展的，但是不可修改，開放封閉有兩個含義，一個對于拓展是開放的，一個對于修改是封閉的。對于開發來說需求肯定是要變化的，但是新需求一來，我們就要把類重新改一遍這顯然是令人頭疼的，所以我們設計程序時面對需求的改變要盡可能的保證相對的穩定，盡量用新代碼實現拓展來修改需求，而不是通過修改原來的代碼來實現。假設我們要實現一個列表，一開始只有查詢的功能，這時產品需要增加添加功能，過幾天又要新增刪除功能，大多人都是寫一個方法通過傳入不同的值來控制方法實現不同的功能，但是如果又要新增功能我們還的修改我們的方法。用開發封閉原則解決就是增加一個抽象的功能類，讓增加和刪除和查詢作為這個抽象類的字類，這樣如果我們在添加功能，你就會發現我們不需要修改原有的類，只需要添加一個功能類的字類實現功能類的方法就可以了。

3.里氏替換原則

定義：所有引用基類（父類）的地方必須能透明的使用其子類的對象，里氏替換原則告訴我們，在軟件中將一個基類對象替換成它的字類對象，程序將不會產生任何錯誤和異常，反過來則不成立，如果一個軟件實體使用的是一個字類對象的話，那么它不一定能夠使用基類對象，里氏替換原則是實現開閉原則的重要方式之一，由于使用基類對象的地方都可以使用字類對象，因此在程序中盡量使用基類類型來對對象進行定義，而在運行時在確定其子類類型，用子類對象來替換父類對象。在使用時需要注意一下幾個地方：

• 子類的所有方法必須在父類中聲明，或子類必須實現父類中的所有方法，根據里氏替換原則，為了保住系統的擴展性，在程序中通常使用父類來進行定義，如果一個方法只存在子類中，在父類中不提供相應的聲明，則無法在以父類定義的對象中使用該方法。
• 我們在運用里氏替換原則時，盡量把父類設計為抽象類或者接口，讓子類繼承父類或實現父接口，并實現父類中聲明的方法，運行時，子類實列替換父類實列，我們可以很方便的擴展系統的功能，同時無需修改原有的子類的代碼，增加新的佛你功能我們可以通過增加一個新的子類來實現，里氏替換原則是開閉原則的具體實現手段之一。

4.依賴倒置原則

定義：高層模塊不應該依賴底層模塊，兩個都應該依賴于抽象。抽象不應該依賴細節，細節應該依賴于抽象。在java中，抽象就是指接口或者抽象類，兩者都是不能直接被實列化的。細節就是實現類，實現接口或者繼承抽象類而產出的就是細節，也就是可以加上一個關鍵字new產生的對象，高層模塊就是調用端，底層模塊就是具體實現類。依賴倒置原則在java中的表現就是：模塊間通過抽象發生，實現類之間不發生直接的依賴關系，其依賴關系是通過接口或抽象類產生的。如果與類直接依賴細節，那么就會直接耦合，那么修改時，就會同時修改依賴者代碼，這樣就限制了可擴展性。

5.迪米特原則

定義：一個軟件實體應當盡可能少得與其他實體發生相互作用。也稱為最少知識原則。如果一個系統符合迪米特原則，那么其中某一個模塊發生修改時，就會盡量少的影響其他模塊，擴展會相對容易，這是對軟件實體之間通信的限制，迪米特原則要求限制團建實體之間通信的寬度和深度。迪米特法則可降低系統的耦合毒，使得類與類保持松散的耦合關系。迪米特原則要求我們在設計系統時，應該盡量減少對象之前的交互，如果兩個對象之間不必彼此通信，那么這兩個對象就不應當發生任何的相互作用，如果其中一個對象需要調用另外一個對象的方法時，可以通過第三者來轉發這個調用，簡言之，就是通過引入一個合理的第三者來降低現有對象之間的耦合度，在將迪米特原則運用到系統設計中時，要注意以下幾點：

• 在類的劃分上，應當盡量創建松耦合的類，類之間的耦合度越低，就越有利于服用，一個處在松耦合中的類一旦被修改，不會對關聯的類照成太大的波動.
• 在類的結構設計上，每一個類都應當降低其成員變量和成員函數的訪問權限，在類的設計上，只要有可能，一個類型應當設計成不變類，在對其他類的引用上，一個對象對其他對象的引用應當降到最低。

6.接口隔離原則

定義：一個類對另一個類的依賴應該建立在最小的接口上，建立單一接口，不要建立龐大臃腫的接口，盡量細化接口，接口中的方法盡量小，也就是說，我們要為各個類建立專用的接口，而不要試圖去建立一個龐大的接口供所有依賴它的類去調用。采用接口隔離原則對接口進行約束時要注意以下幾點：

• 接口盡量小，但是要有限度，對接口進行細化哭提高程序設計靈活性，但是如果過小，則會照成接口數量過多，使設計復雜化，所以一定要適度。
• 為依賴接口的類定制服務，只暴露給調用的類需要的方法，它不需要的方法則隱藏起來，只有專注地為一個模塊提供定制服務，才能建立最小的依賴關系，提高內聚，減少對外交互，使接口用最少的方法完成最多的事情。