1.開閉原則。
乙個軟體實體，如類，模組和函式應該對外擴充套件開發，對內修改關閉。
解讀：用抽象構建框架，用實現擴充套件細節。不以改動原有類的方式來實現新需求，而是應該以實現事先抽象出來的介面（或具體類繼承抽象類）的方式來實現。
優點：開閉原則的優點在於可以在不改動原有**的前提下給程式擴充套件功能。增加了程式的可擴充套件性，同時也降低了程式的維護成本。
2.單一職責原則。
乙個類只允許有乙個職責，即只有乙個導致該類變更的原因。
解讀：類職責的變化往往就是導致類變化的原因：也就是說如果乙個類具有多種職責，就會有多種導致這個類變化的原因，從而導致這個類的維護變得困難。往往在軟體開發中，隨著需求的不斷增加，可能會給原來的類新增一些本來不屬於它的一些職責，從而違反了單一職責原則。如果我們發現當前類的職責不僅僅有乙個，就應該將本來不屬於該類真正的職責分離出去。不僅僅是類，函式也要遵循單一職責原則，即乙個函式製作一件事情。如果發現乙個函式裡面有不同的任務，則需要將不同的任務以另乙個函式的形式分離出去。
優點：如果類與方法的職責劃分的很清晰，不但可以提高**的可讀性，更實際性地更降低了程式出錯的風險，因為清晰的**會讓bug無處藏身，也有利於bug的追蹤，也就是降低了程式的維護成本。
3.依賴倒置原則。
依賴抽象而不是依賴實現。抽象不應該依賴細節，細節應該依賴抽象。高層模組不能依賴低層模組，二者都應該依賴抽象。
解讀：針對介面程式設計，而不是針對實現程式設計。盡量不要從具體的類派生，而是以繼承抽象類或實現介面來實現。關於高層模組與低層模組的劃分可以按照決策能力的高低進行劃分。業務層自然就處於上層模組，邏輯層和資料層自然就歸類為底層。
優點：通過抽象來搭建框架，建立類和類的關聯，以減少類間的耦合性。而且以抽象搭建的系統要比以具體實現搭建的系統更加穩定，擴充套件性更高，同時也便於維護。
4.介面分離原則。
多個特定的客戶端介面要好於乙個通用性的總介面。
解讀：客戶端不應該依賴它不需要實現的介面。不建立龐大臃腫的介面，應盡量細化介面，介面中的方法應盡量少。需要注意的是介面的力度也不能太小，如果過小，則會造成介面數量過多，使設計複雜化。
優點：避免同乙個介面裡面包含不同類職責的方法，介面責任劃分更加明確，符合高內聚低耦合的思想。
5.迪公尺特法則
乙個物件應該對盡可能少的物件有接觸，也就是只接觸那些真正需要接觸的物件。
解讀：迪公尺特法則也叫做最少知道原則，乙個類應該只和它的成員變數，方法的輸入，返回引數中的類作交流，而不應該引入其他的類（間接交流）。
優點：實踐迪公尺特法則可以良好地降低類與類之間的耦合，減少類與類之間的關聯程度，讓類與類之間的協作更加直接。
6.黎克特制替換原則。
所有引用基類的地方必須能透明地使用其子類的物件，也就是說子類物件可以替換其父類物件，而程式執行效果不變。
解讀：在繼承體系中，子類中可以增加自己特有的方法，也可以實現父類的抽象方法，但是不能重寫父類的非抽象方法，否則該繼承關係就不是乙個正確的繼承關係。
優點：可以檢驗繼承使用的正確性，約束繼承在使用上的氾濫。
設計模式六大原則
0.05 設計模式 設計模式 規範 筆記 大話設計模式 物件導向的關鍵在於封裝，封裝好了才能很好的復用，達到單一職責和開放擴充套件 封閉更改的效果。1 單一職責原則 就乙個類而言,應該僅有乙個引起它變化的原因.增加功能不應該修改已有的 避免修改出錯及重複測試.如果你能夠想到多於乙個的動機去改變乙個類...
設計模式六大原則
0.05 設計模式 設計模式 規範 筆記 大話設計模式 物件導向的關鍵在於封裝，封裝好了才能很好的復用，達到單一職責和開放擴充套件 封閉更改的效果。1 單一職責原則 就乙個類而言,應該僅有乙個引起它變化的原因.增加功能不應該修改已有的 避免修改出錯及重複測試.如果你能夠想到多於乙個的動機去改變乙個類...
設計模式六大原則
參考文章 單一職責原則 single responsibility principle,srp 乙個類只負責乙個功能領域中的相應職責，或者可以定義為 就乙個類而言，應該只有乙個引起它變化的原因。開閉原則 open closed principle,ocp 乙個軟體實體應當對擴充套件開放，對修改關閉。...