單一職責：
例子：iphone介面中有三個方法
dial --撥號
chat --通話
hangup --結束通話**
由於撥號 和 結束通話**是屬於協議，而通話屬於業務，所以對介面進行拆分
iconnector介面
dial --撥號
hangup --結束通話**
idatatransfer介面
chat --通話
總結：對介面，有且僅有乙個原因引起介面的變化。上面的例子協議 和 資料傳輸的變化都會引起iphone介面的變化，所以要拆分
對類，盡力做到有且僅有乙個原因引起類的變化，這個通常很難。
對方法，有且僅有乙個原因引起方法的變化。
黎克特制替換原則
所有引用基類的地方必須能透明的使用其子類的物件；反之不行，子類出現的地方，父類未必能適應。
例子：士兵打槍，槍是父類，子類有多個實現。
4原則a 子類必須完全實現父類的方法
b 子類可以有自己的個性
c 覆蓋或實現父類的方法時，輸入引數可以被放大
class father
public static void main(string args)
public static void invoker()
}class son extends father
}d 覆蓋或實現父類的方法時，輸出結果可以被縮小。
依賴倒置原則
模組之間的依賴通過抽象發生，實現類之間不直接發生依賴，依賴通過介面或抽象類產生
介面或抽象類不依賴於實現類，實現類依賴於介面或抽象類
這就是所謂的面向介面程式設計
例子：司機開汽車，汽車是個介面，有多個實現類，司機呼叫介面即可。
依賴倒置三個寫法：建構函式，set/get，介面中寫
介面隔離原則
客戶端不應該依賴它不需要的介面。從模組角度考慮，乙個模組應該依賴他所需功能的介面，不需要的就不要寫。
例子：女孩介面：臉蛋、身材、氣質。 但是氣質每個時代不同，所以需要隔離
女孩介面1：臉蛋、身材
女孩介面2：氣質
然後用女孩實現介面1 和 介面2
迪公尺特法則
對呼叫的類知道的越少越好。最好只知道public方法，耦合性最低最好。
4個原則
a 乙個類只和朋友交流，朋友指屬性、方法的輸入輸出引數。
例子：老師 命令 體委 清點 學生。
老師只和體委交流，體委清點學生，學生的數量放在場景類中，而不是老師中。
b 乙個類和朋友是有舉例的不能太近，也不能太遠。
例子：軟體安裝步驟
不能將所有的步驟暴露出來，將步驟封裝在乙個方法中，將這個方法暴露出來
c 是自己的就是自己的。乙個類放在本類中可以，放在其他類中也可以，那麼就放在本類中。
d 謹慎使用serializable，在用rmi時，服務端和客戶端修改要同步。
開閉原則
乙個軟體實體，如模組、類、抽象、方法，對擴充套件開放，對修改關閉.
例子：書店的例子
所有的書打9折，繼承原來的類，重寫**方法，這樣就是擴充套件而不是修改。
solid
s：單一職責----single responsibility principle
o:開閉原則----open closed principle
l:黎克特制替換----liskov substitution principle
l:迪公尺特 ----law of demeter
i:介面隔離----inte***ce segregation principle
d:依賴倒置----dependence inverse principle
設計模式 （六）設計模式原則
1 開閉原則 ocp 是程式設計中最基礎也是最重要的設計原則 2 乙個軟體實體如類，模組和函式應該對擴充套件開放 提供方 對修改關閉 使用方 用抽象構建框架，用實現擴充套件細節。3 當軟體需要變化時，盡量通過擴充套件軟體實體的行為來實現變化，而不是通過修改已有的 來實現變化。4 程式設計中使用其他原...
設計模式六大設計原則之開閉原則
開閉原則 1 定義 乙個軟體實體如類 模組和函式應該對擴充套件開放，對修改關閉。2 問題由來 在軟體的生命週期內，因為變化 公升級和維護等原因需要對軟體原有 進行修改時，可能會給舊 中引入錯誤，也可能會使我們不得不對整個功能進行重構，並且需要原有 經過重新測試。3 解決方案 當軟體需要變化時，盡量通...
設計模式之六大設計原則（一）
單一職責原則是我們設計模式中最簡單也是最容易理解的物件導向設計原則，我們先來看一下單一職責原則的定義 單一職責原則 就乙個類而言，應該僅有乙個引起它變化的原因。通俗來講就是乙個類它只負責單一的功能，切不可做的太多。在軟體中乙個類 大到乙個模組，小到乙個方法 如果所具有的功能越多，那麼它就越複雜，復用...