定義：乙個物件應該只包含單一的職責，並且該職責被完整地封裝在乙個類中。即：不要存在多於乙個導致類變更的原因。通俗的說，就是乙個類只負責一項職責。
問題由來：類t負責兩個不同的職責：職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。
解決方案：遵循單一職責原則。分別建立兩個類t1、t2，使t1完成職責p1功能，t2完成職責p2功能。這樣，當修改類t1時，不會使職責p2發生故障風險；同理，當修改t2時，也不會使職責p1發生故障風險。
雖然單一職責原則看起來如此簡單，但由於職責擴散，即便是經驗豐富的程式設計師寫出的程式，也會有違背這一原則的**存在。所謂職責擴散，就是因為某種原因，職責p被分化成粒度更細的職責p1和p2。
比如：開始時，類t只負責乙個職責p，這符合單一職責原則。後來由於某種原因，需要將職責p細分為粒度更細的職責p1、p2，這時如果要使程式遵循單一職責原則，需要將類t也分解為兩個類t1和t2，來分別負責p1、p2兩個職責。但是在程式已經寫好的情況下，這樣做將會耗費大量時間和精力，所以，簡單地修改類t，用它來負責兩個職責是乙個比較不錯的選擇，雖然這違背了單一職責原則。
舉例說明，用乙個類描述動物吃東西這個場景：
class animal
}public class client
}執行結果：
牛吃草羊吃草
馬吃草
程式上線後，發現問題了，並不是所有的動物都是吃草的，比如狼就是吃肉的。修改時如果遵循單一職責原則，需要將animal類細分為食草動物herbivore和肉食性動物carnivora，**如下：
class herbivore
}class carnivora
}public class client
} 執行結果：
牛吃草羊吃草
馬吃草狼吃肉
我們發現這樣修改花銷是很大的，除了將原來的類分解之外，還需要修改客戶端。而直接修改類animal來達成目的雖然違背了單一職責原則，但花銷卻要小的多，**如下：
class animalelse
}}public class client
}
可以看到，這種修改方式要簡單得多，但是卻存在著隱患：有一天需要將狼分為北極狼和非北極狼，則又需要修改animal類的eat方法，而對原有**的修改會呼叫「牛」、「羊」、「馬」等相關功能帶來風險，也許某一天你會發現程式執行結果變成了「非北極狼吃草」了。這種修改方式直接在**級別上違背了單一職責原則，雖然修改起來最簡單，但是隱患也是最大的。還有一種修改方式：
class animal
public void eat2(string animal)
}public class client
}
可以看到，這種修改方式沒有改動原來的方法，而是在類中新加了乙個方法，這樣雖然也違背了單一職責原則，但在方法級別上卻是符合單一職責原則的，因為它並沒有動原來方法的**。
這三種方式各有優缺點，那麼在實際程式設計中，採用哪一種呢？其實這真的比較難說，需要根據實際情況來確定。我的原則是：只有邏輯足夠簡單，才可以在**級別上違反單一職責原則；只有類中方法數量足夠少，才可以在方法級別上違反單一職責原則。在實際應用中的類都要複雜得多，一旦發生職責擴散而需要修改類時，除非這個類本身非常簡單，否則還是遵循單一職責原則的好。
遵循單一職責原則的優點：
1、降低類的複雜性，類的職責清晰明確；
2、提高類的可讀性和可維護性；
3、變更引起的風險降低，變更是必然的，如果單一職責原則遵守的好，當修改乙個功能時，可以顯著降低對其他功能的影響。
原文：
設計模式原則 單一職責原則
對類來說的，即乙個類應該只負責一項職責。假如類a負責多項職責，當其中一項職責需求發生變更時，可能對其他職責的執行造成影響。例如 類a負責實現 訂單資料持久化 職責 和 使用者資料持久化 職責，那麼當我們需要修改 使用者資料持久化 需求時，由於 糅雜在乙個類裡，可能會對 訂單資料持久化 的職責造成影響...
設計模式原則 單一職責原則
1.概念 對類來說的，即乙個類應該只負責一項職責。如類a負責兩個不同職責 職責1，職責2。當職責1需求變更而改變a時，可能造成職責2執行錯誤，所以需要將類a的粒度分解為a1，a2。2.問題的提出 package com.atguigu.principle.singleresponsibility p...
設計原則 單一職責原則
定義 不要存在多於乙個導致類變更的原因。通俗的說，即乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 遵循單一職責原則。分別建立兩個類t1 t2，使t1完成職責p1功能，t...