單一職責原則(single responsibility principle, srp)：乙個類只負責乙個功能領域中的相應職責，或者可以定義為：就乙個類而言，應該只有乙個引起它變化的原因。
原因:這樣的話，每個類只需要負責自己的那部分，類的複雜度就會降低。如果職責劃分得很清楚，那麼**維護起來也更加容易。試想如果所有的功能都放在了乙個類中，那麼這個類就會變得非常臃腫，而且一旦出現bug，要在所有**中去尋找；更改某乙個地方，可能要改變整個**的結構，想想都非常可怕。當然一般時候，沒有人會去這麼寫的。
當然，這個原則不僅僅適用於類，對於介面和方法也適用，即乙個介面/方法，只負責一件事，這樣的話，介面就會變得簡單，方法中的**也會更少，易讀，便於維護。
事實上，由於一些其他的因素影響，類的單一職責在專案中是很難保證的。通常，介面和方法的單一職責更容易實現。
優點:
舉例說明，用乙個類描述動物呼吸這個場景：
class
animal
}public
class
client
}
牛呼吸空氣
羊呼吸空氣
豬呼吸空氣
程式上線後，發現問題了，並不是所有的動物都呼吸空氣的，比如魚就是呼吸水的。修改時如果遵循單一職責原則，需要將animal類細分為陸生動物類terrestrial，水生動物aquatic，**如下：
class
terrestrial
}class
aquatic
}public
class
client
}
牛呼吸空氣
羊呼吸空氣
豬呼吸空氣
魚呼吸水
我們會發現如果這樣修改花銷是很大的，除了將原來的類分解之外，還需要修改客戶端。而直接修改類animal來達成目的雖然違背了單一職責原則，但花銷卻小的多，**如下：
class
animal
else}}
public
class
client
}
class
animal
public
void
breathe2
(string animal)
}public
class
client
}
設計模式原則 單一職責原則
定義 乙個物件應該只包含單一的職責，並且該職責被完整地封裝在乙個類中。即 不要存在多於乙個導致類變更的原因。通俗的說，就是乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 ...
設計模式原則 單一職責原則
對類來說的，即乙個類應該只負責一項職責。假如類a負責多項職責，當其中一項職責需求發生變更時，可能對其他職責的執行造成影響。例如 類a負責實現 訂單資料持久化 職責 和 使用者資料持久化 職責，那麼當我們需要修改 使用者資料持久化 需求時，由於 糅雜在乙個類裡，可能會對 訂單資料持久化 的職責造成影響...
設計模式原則 單一職責原則
1.概念 對類來說的，即乙個類應該只負責一項職責。如類a負責兩個不同職責 職責1，職責2。當職責1需求變更而改變a時，可能造成職責2執行錯誤，所以需要將類a的粒度分解為a1，a2。2.問題的提出 package com.atguigu.principle.singleresponsibility p...