android移動架構彙總
設計模式六大原則：
單一職責原則
黎克特制替換原則
介面隔離原則
依賴倒置原則
迪公尺特法則
開閉原則
一、單一職責原則
1、定義
單一原則（srp：single responsibility principle）又稱單一職責原則。它規定乙個類應該只有乙個發生變化的原因。通俗的說，即乙個類只負責一項職責。
問題由來：類t如果負責兩個不同的職責：職責p1、職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。
解決方案：遵循單一職責原則，分別建立兩個類t1、t2，使t1完成職責p1功能，t2完成職責p2功能。這樣當修改類t1時，不會使職責p2發生故障風險；同理，當修改t2時，也不會使職責p1發生故障。
2、案例
在軟體程式設計中，遵循單一職責原則可以避免修改乙個功能導致其它的功能發生故障。但即便是經驗豐富的程式設計師寫出的程式，也會有違背這一原則的**存在。因為有職責擴散（因為某種原因，職責p被分化為粒度更小的職責p1和p2）
比如：類t只負責乙個職責p，這樣設計是符合單一職責原則的，但後來由於某種原因，需要將職責p細分為粒度更細的職責p1、p2，這時如果要使程式遵循單一職責原則，需要將類t也分解為兩個類t1和t2，分別負責p1、p2兩個職責。但是在程式已經寫好的情況下，這樣做簡直太浪費時間。所有簡單的修改類t，用來來負責兩個職責是乙個比較不錯的選擇，雖然這樣做有悖於單一職責原則。（這樣做的風險在於職責擴散的不確定性，因為我們不會想到這個職責p，在未來可能會擴散為p1、p2、p3...pn。所以記住，在職責擴散到我們無法控制的程度之前，立刻對**進行重構。）
例如，1）動物需要呼吸的原始需求：剛開始只有牛、羊呼吸空氣
public class animal
}
執行結果：public class client
}
牛呼吸空氣
羊呼吸空氣
2）需求修改：新增魚呼吸水
第一種方法：修改時如果遵循單一職責原則，需要將animal細分為陸生動物類terrestrial，水生動物aquatic，**如下：
public class terrestrial
}
呼叫：public class aqutic
}
執行結果：public class client
}
牛呼吸空氣
羊呼吸空氣
魚呼吸水
我們會發現如果這樣修改花銷是很大的，除了將原來的類分解之外，還需要修改客戶端。
第二種方法：直接修改類animal來達成目的，雖然違背了單一職責原則，但花銷卻小的多，**如下：
呼叫：public class animal else
}}
public class client
}
執行結果：
牛呼吸空氣
羊呼吸空氣
魚呼吸水
這種修改方式要簡單的多，但是卻存在著隱患：有一天將魚分為呼吸淡水的魚和呼吸海水的魚，則又要修改animal類的breathe方法，而對原有**的修改會呼叫「牛」「羊」等相關功能帶來風險，也許有一天你會發現程式執行的結果變為「牛呼吸水」了。這種修改方式直接在**級別違背了單一職責原則，雖然修改起來最簡單，但隱患卻是最大的。
第三種修改方式：
呼叫：public class animalpublic void breathe1(string animal)
}
結果：public class client
}
牛呼吸空氣
羊呼吸空氣
魚呼吸水
3）總結
可以看到，第三種修改方式沒有改動原來的方法，而是在類中新加乙個方法，這樣雖然也違背了單一職責原則，但在方法級別上卻是符合單一職責原則的，因為它並沒有動原來方法的**。這三種方式各有優缺點。那麼在實際程式設計中，採用哪一種呢？其實這真的比較難說，需要根據實際情況來確定。一般參考的原則：只有邏輯足夠簡單，才可以在**級別上違反單一職責原則；只有類中方法數量足夠少，才可以在方法級別上違反單一職責原則，否則還是遵循單一職責原則的好。在當前案例中使用第三種方案是推薦的
三、特點
1、降低類的複雜性，對類或介面的職責有清晰明確定義，乙個類只負責一項職責，其邏輯肯定要比負責多項職責簡單的多；
2、提高可讀性，提高系統的可維護性
3、降低變更引起的風險，介面改變只影響相應的實現類，不影響其他類
需要說明的一點是單一職責原則不只是物件導向程式設計思想所持有的，只要是模組化的程式設計，都適用單一職責原則。
四、重點
1、介面一定要做到單一職責
2、類的單一職責比較難以實現，盡量做到只有乙個原因引起變化；
3、乙個方法盡可能做一件事，能分解就分解，分解到原子級別。
移動架構28 設計模式六大原則六 開閉原則
android移動架構彙總 設計模式六大原則 單一原則 黎克特制替換原則 介面隔離原則 依賴倒置原則 迪公尺特法則 開閉原則 1 定義 軟體的實體類,模組,函式應該對擴充套件開放,對修改關閉 即 軟體實體應該通過擴充套件實現變化,不是通過修改已有的 實現變化 問題由來 在軟體的生命週期內，因為變化 ...
一 設計模式六大原則
1 開閉原則 對擴充套件開發，對修改關閉。實現開閉原則的關鍵就在於 抽象 把系統的所有可能的行為抽象成乙個抽象底層，這個抽象底層規定出所有的具體實現必須提供的方法的特徵。作為系統設計的抽象層，要預見所有可能的擴充套件，從而使得在任何擴充套件情況下，系統的抽象底層不需修改 同時，由於可以從抽象底層匯出...
設計模式六大原則
0.05 設計模式 設計模式 規範 筆記 大話設計模式 物件導向的關鍵在於封裝，封裝好了才能很好的復用，達到單一職責和開放擴充套件 封閉更改的效果。1 單一職責原則 就乙個類而言,應該僅有乙個引起它變化的原因.增加功能不應該修改已有的 避免修改出錯及重複測試.如果你能夠想到多於乙個的動機去改變乙個類...