最近在看android 原始碼設計模式，所以打算每看完一節，結合自己專案與經驗寫點讀後感。
單一職責 用程式語言來說 就是 把能拆的** 都拆了。其實這句話對應的就是單一原則，低耦合。是開發中很常見的
寫法。但是怎麼拆，哪些要拆 就是難點了。書上舉了乙個載入器的例子，但是由於這例子寫的人少，一般載入
都用框架了。手動寫比較少。我就舉個常見的，那就是 大家寫**時 ，都會先尋找view，然後聯網操作，最後
填充資料的 。 其實大多數人都會寫幾個方法 initview(),initdata(),setup(),這裡的把 乙個介面操作，分解成幾個方法也是
單一原則。單一原則就是 把某一部分 業務邏輯 拆分 成乙個類，或者乙個方法 ，以後呼叫的時候，呼叫這個類或者
方法就行。再舉乙個例子，每個人都用過 utils這個類。這個就是很簡單的單一原則，還有大家的使用框架，也是單一原則。
單一原則比較簡單。只是 什麼時候用呢， 我個人認為
1.重複比較多的時候
2.**比較臃腫的時候。
3.業務邏輯關聯不是很大的時候。比如 乙個負責載入布局，乙個負責載入資料。
等等。
設計模式六大原則之 單一職責原則
規定乙個類只有乙個發生變化的原因。通俗理解為 乙個類只負責一項職責。類t負責兩個不同的職責，當職責p1改變需求時需要修改t類,這時候就有可能因為修改的邏輯導致職責p2出現故障 遵循單一原則，建立兩個類t1和t2，在修改t1的時候不會影響t2，同理，修改t2的時候也不影響t1的邏輯 類的單一職責比較難...
設計模式七大原則之單一職責原則
單一職責原則 不要存在多於乙個導致類變更的原因。通俗的說，即乙個類只負責一項職責。也就是類a 如果負責兩項任務t1和t2，如果當t1職責需求變更需要修改類a，可能會對t2導致影響或故障 這個時候我們就需要將任務t1和t2分離開來，遵循單一原則，既修改t1，t2不受影響 舉個例子 class anim...
設計模式六大原則 單一職責原則
設計模式六大原則 1 單一職責原則 定義 不要存在多於乙個導致類變更的原因。通俗的說，即乙個類只負責一項職責，乙個人只負責做一件事。乙個類，只有乙個引起它變化的原因。應該只有乙個職責。每乙個職責都是變化的乙個軸線，如果乙個類有乙個以上的職責，這些職責就耦合在了一起。這會導致脆弱的設計。當乙個職責發生...