1.單一職責原則(single responsibility principle)：
對乙個類而言，應該僅有乙個引起它變化的原因。如果存在多於乙個動機去改變乙個類，那麼這個類就具有多於乙個的職責，就應該把多餘的職責分離出去，再去建立一些類來完成每乙個職責。單一職責原則是實現高內聚低耦合的最好方法，沒有之一。
2.黎克特制替換原則(liskov's substitution principle)：
子類可以擴充套件父類的功能，但是不能改變父類原有的功能。
繼承必須明確確保超類（父類）所擁有的性質在子類中仍然成立。
所有用父類的地方都可以用子類替換，子類不會override修改父類的方法，只會擴充套件
3.依賴倒置原則(dependency inversion principle)：
設計程式時，要依賴抽象類、介面，而不是具體的實現類，高層模組不應該依賴底層模組，二者都應該依賴其抽象和介面；抽象不依賴細節；細節應該依賴抽象，面向介面程式設計。
4.介面隔離原則(inte***ce segregation principle)：
客戶端不應該依賴它不需要的介面，類間的依賴關係應該建立在最小的介面上，介面盡量細化，同時保證介面中的方法盡量的少。
回到上述的單一職責原則，要求行為分離介面介面細化，感覺有些相同。單一職責原則要求類與介面的職責單一，注重的是職責，沒有要求介面盡量的少。
在介面隔離原則中，要求盡量使用多個專門的介面。專門的介面也就是提供給多個模組的介面。提供給幾個模組就應該有幾個介面，而不是建立乙個臃腫龐大的介面，所有的模組都可以訪問。
但是介面的設計是有限度的。介面的設計粒度越小系統越靈活，這是事實，但是介面太多這也就使得結構複雜，維護難度大。因此實際中，怎樣把握就靠開發的經驗和常識了。
5.開閉原則(open close principle)：
對擴充套件開放，對修改關閉。
已經完成並測試過的**，應該盡量少的去改動它 ，以免引起新的問題。我們可以建立抽象類來隔離之後發生的變化。
6.迪公尺特法則（law of demeter）又叫最少知識原則（least knowledge principle）:
乙個物件應當對其他物件有盡可能少的了解,不和陌生人說話。
迪公尺特法則不希望類之間建立直接的聯絡。如果真的有需要建立聯絡，也希望能通過它的友元類來轉達。因此，應用迪公尺特法則有可能造成的乙個後果就是：系統中存在大量的中介類，這些類之所以存在完全是為了傳遞類之間的相互呼叫關係——這在一定程度上增加了系統的複雜度。
設計模式六大原則
0.05 設計模式 設計模式 規範 筆記 大話設計模式 物件導向的關鍵在於封裝，封裝好了才能很好的復用，達到單一職責和開放擴充套件 封閉更改的效果。1 單一職責原則 就乙個類而言,應該僅有乙個引起它變化的原因.增加功能不應該修改已有的 避免修改出錯及重複測試.如果你能夠想到多於乙個的動機去改變乙個類...
設計模式六大原則
0.05 設計模式 設計模式 規範 筆記 大話設計模式 物件導向的關鍵在於封裝，封裝好了才能很好的復用，達到單一職責和開放擴充套件 封閉更改的效果。1 單一職責原則 就乙個類而言,應該僅有乙個引起它變化的原因.增加功能不應該修改已有的 避免修改出錯及重複測試.如果你能夠想到多於乙個的動機去改變乙個類...
設計模式六大原則
參考文章 單一職責原則 single responsibility principle,srp 乙個類只負責乙個功能領域中的相應職責，或者可以定義為 就乙個類而言，應該只有乙個引起它變化的原因。開閉原則 open closed principle,ocp 乙個軟體實體應當對擴充套件開放，對修改關閉。...