單一職責原則
開閉原則
依賴倒轉原則
黎克特制替換原則
介面隔離原則
合成聚合復用原則
迪公尺特法則
乙個類只做它該做的事情。
單一職責原則的核心就是高內聚，即乙個 模組只完成一項功能。單一職責，顧名思義就是乙個類只有乙個職責，只做一件事情。我們在大學裡學的軟體工程和軟體專案管理中，老師都在強調軟體設計要追求「高內聚、低耦合」，以提高模組的重用性和移植性，而單一職責原則就很好的說明了高內聚。
乙個軟體實體應當對擴充套件開放，對修改關閉。即軟體實體應盡量在不修改原有**的情況下進行擴充套件。
開閉原則的關鍵就是抽象化，我們在**編寫的時候，先利用介面和抽象類構建好乙個相對穩定的抽象層，而將具體的功能在實現層中編寫。如果需要修改或擴充系統的行為，無須對抽象層進行任何改動，只需要增加新的具體類來實現新的業務功能即可，達到在進行功能拓展時無序修改現有**的效果，達到開閉原則的要求。
程式要依賴於抽象介面，不依賴於具體實現。
直白的講就是我們常提到的面向介面程式設計。宣告方法的引數型別、方法的返回型別、變數的引用型別時，盡可能使用抽象型別而不用具體型別，因為抽象型別可以被它的任何乙個子型別所替代。
任何時候都可以用子型別替換掉父型別。
因為子類是增強父類的能力，而不是減少父類的能力，所以用父型別的地方就一定能使用子型別。黎克特制替換原則可以檢查繼承關係是否合理，如果乙個繼承關係違背了黎克特制替換原則，那麼這個繼承關係一定是錯誤的，需要對**進行重構。
介面要小而專，絕不能大而全。
不能把介面設計的過於臃腫和複雜。例如，琴棋書畫就應該分別設計為四個介面，而不應設計成乙個介面中的四個方法，因為如果設計成乙個介面中的四個方法，那麼這個介面很難用，畢竟琴棋書畫四樣都精通的人還是少數，而如果設計成四個介面，會幾項就實現幾個介面，這樣的話每個介面被復用的可能性是很高的。
優先使用聚合或合成關係復用**。
組合和聚合都是物件建模中關聯（association）關係的一種。聚合表示整體與部分的關係，表示「含有」，整體由部分組合而成，部分可以脫離整體作為乙個獨立的個體存在。組合則是一種更強的聚合，部分組成整體，而且不可分割，部分不能脫離整體而單獨存在。在類與類之間簡單的說有三種關係，is-a關係、has-a關係、use-a關係，分別代表繼承、關聯和依賴。聚合和合成都屬於關聯關係。
其他大佬那裡看到的乙個比較好的例子：
我們需要辦理一張銀行卡，如果銀行卡預設都擁有了存款、取款和透支的功能，那麼我們辦理的卡都將具有這個功能，此時使用了繼承關係：
為了靈活地擁有各種功能，此時可以分別設立儲蓄卡和信用卡兩種，並有銀行卡來對它們進行聚合使用。此時採用了合成復用原則:
乙個物件應該對其他的物件有盡可能少的了解，又叫最少知識原則。
這個具體講指的就是低耦合，由於每個類儘量減少對其他類的依賴，因此，很容易使得系統的功能模組功能獨立，相互之間不存在（或很少有）依賴關係。設計模式中的門面模式（facade）和中介模式（mediator），都是迪公尺特法則應用的例子。
其含義時引入乙個第三方中介類，這個類集合了多個零部件類的功能，實際功能則委託給這些零部件物件，這個類只是做為對外統一介面，只是乙個馬甲。
其含義是用乙個中介物件來封裝一系列的物件互動。中介者使個物件不需要顯示地相互引用，從而使其耦合鬆散，而且可以獨立地改變它們之間的互動。即通過乙個中介類接受所有訊息，然後再進行**。
物件導向的六原則之介面隔離原則
記得在操作io流時，在最後要關閉流的時候要try catch，流多的時候就有一大堆try catch，如下所示 private void put string path,bitmap bitmap catch filenotfoundexception e finally catch ioexcep...
物件導向設計原則 迪公尺特法則
迪公尺特法則 law of demeter,lod 乙個軟體實體應當盡可能少地與其他實體發生相互作用。如果乙個系統符合迪公尺特法則，那麼當其中某乙個模組發生修改時，就會盡量少地影響其他模組，擴充套件會相對容易，這是對軟體實體之間通訊的限制，迪公尺特法則要求限制軟體實體之間通訊的寬度和深度。迪公尺特法...
關於《物件導向六大原則》的解讀
目錄 一 srp 單一職責原則 single responsibility priciple 二 ocp 開閉原則 open close principle 讓程式更穩定靈活 三 lsp 黎克特制替換原則 liskov substitution principle 讓程式擴充套件性更好 四 dip ...