定義：不要存在多於乙個導致類變更的原因。通俗的說，即乙個類只負責一項職責。
問題由來：類t負責兩個不同的職責：職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。
解決方案：遵循單一職責原則。分別建立兩個類t1、t2，使t1完成職責p1功能，t2完成職責p2功能。這樣，當修改類t1時，不會使職責p2發生故障風險；同理，當修改t2時，也不會使職責p1發生故障風險。
單一職責原則是最簡單的物件導向設計原則，它用於控制類的粒度大小。單一職責原則定義如下：
單一職責原則(single responsibility principle, srp)：乙個類只負責乙個功能領域中的相應職責，或者可以定義為：就乙個類而言，應該只有乙個引起它變化的原因。
單一職責原則告訴我們：乙個類不能太「累」！在軟體系統中，乙個類（大到模組，小到方法）承擔的職責越多，它被復用的可能性就越小，而且乙個類承擔的職責過多，就相當於將這些職責耦合在一起，當其中乙個職責變化時，可能會影響其他職責的運作，因此要將這些職責進行分離，將不同的職責封裝在不同的類中，即將不同的變化原因封裝在不同的類中，如果多個職責總是同時發生改變則可將它們封裝在同一類中。
單一職責原則是實現高內聚、低耦合的指導方針，它是最簡單但又最難運用的原則，需要設計人員發現類的不同職責並將其分離，而發現類的多重職責需要設計人員具有較強的分析設計能力和相關實踐經驗。
說到單一職責原則，很多人都會不屑一顧。因為它太簡單了。稍有經驗的程式設計師即使從來沒有讀過設計模式、從來沒有聽說過單一職責原則，在設計軟體時也會自覺的遵守這一重要原則，因為這是常識。在軟體程式設計中，誰也不希望因為修改了乙個功能導致其他的功能發生故障。而避免出現這一問題的方法便是遵循單一職責原則。雖然單一職責原則如此簡單，並且被認為是常識，但是即便是經驗豐富的程式設計師寫出的程式，也會有違背這一原則的**存在。為什麼會出現這種現象呢？因為有職責擴散。所謂職責擴散，就是因為某種原因，職責p被分化為粒度更細的職責p1和p2。
比如：類t只負責乙個職責p，這樣設計是符合單一職責原則的。後來由於某種原因，也許是需求變更了，也許是程式的設計者境界提高了，需要將職責p細分為粒度更細的職責p1，p2，這時如果要使程式遵循單一職責原則，需要將類t也分解為兩個類t1和t2，分別負責p1、p2兩個職責。但是在程式已經寫好的情況下，這樣做簡直太費時間了。所以，簡單的修改類t，用它來負責兩個職責是乙個比較不錯的選擇，雖然這樣做有悖於單一職責原則。（這樣做的風險在於職責擴散的不確定性，因為我們不會想到這個職責p，在未來可能會擴散為p1，p2，p3，p4……pn。所以記住，在職責擴散到我們無法控制的程度之前，立刻對**進行重構。）
舉例說明，用乙個類描述動物呼吸這個場景：
1 class animal5 }
1 public class client執行結果：128 }
345牛呼吸空氣
羊呼吸空氣
豬呼吸空氣
程式上線後，發現問題了，並不是所有的動物都呼吸空氣的，比如魚就是呼吸水的。修改時如果遵循單一職責原則，需要將animal類細分為陸生動物類terrestrial，水生動物aquatic，**如下：
1 class terrestrial5 }
1 class aquatic5 }
1 public class client執行結果：1211 }
3456
7牛呼吸空氣
羊呼吸空氣
豬呼吸空氣
魚呼吸水
我們會發現如果這樣修改花銷是很大的，除了將原來的類分解之外，還需要修改客戶端。而直接修改類animal來達成目的雖然違背了單一職責原則，但花銷卻小的多，**如下：
1 class animalelse8 }
9 }
1 public class client可以看到，這種修改方式要簡單的多。但是卻存在著隱患：有一天需要將魚分為呼吸淡水的魚和呼吸海水的魚，則又需要修改animal類的breathe方法，而對原有**的修改會對呼叫「豬」「牛」「羊」等相關功能帶來風險，也許某一天你會發現程式執行的結果變為「牛呼吸水」了。這種修改方式直接在**級別上違背了單一職責原則，雖然修改起來最簡單，但隱患卻是最大的。還有一種修改方式：9 }
1 class animal5 6 public void breathe2(string animal)
9 }
1 public class client可以看到，這種修改方式沒有改動原來的方法，而是在類中新加了乙個方法，這樣雖然也違背了單一職責原則，但在方法級別上卻是符合單一職責原則的，因為它並沒有動原來方法的**。這三種方式各有優缺點，那麼在實際程式設計中，採用哪一中呢？其實這真的比較難說，需要根據實際情況來確定。我的原則是：只有邏輯足夠簡單，才可以在**級別上違反單一職責原則；只有類中方法數量足夠少，才可以在方法級別上違反單一職責原則；9 }
例如本文所舉的這個例子，它太簡單了，它只有乙個方法，所以，無論是在**級別上違反單一職責原則，還是在方法級別上違反，都不會造成太大的影響。實際應用中的類都要複雜的多，一旦發生職責擴散而需要修改類時，除非這個類本身非常簡單，否則還是遵循單一職責原則的好。
遵循單一職責原的優點有：
需要說明的一點是單一職責原則不只是物件導向程式設計思想所特有的，只要是模組化的程式設計，都適用單一職責原則。
參考：設計模式六大原則
設計模式六大原則（1） 單一職責原則
定義 不要存在多於乙個導致類變更的原因。通俗的說，即乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 遵循單一職責原則。分別建立兩個類t1 t2，使t1完成職責p1功能，t...
設計模式六大原則（1） 單一職責原則
定義 不要存在多於乙個導致類變更的原因。通俗的說，即乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 遵循單一職責原則。分別建立兩個類t1 t2，使t1完成職責p1功能，t...
設計模式六大原則（1） 單一職責原則
定義 不要存在多於乙個導致類變更的原因。通俗的說，即乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 遵循單一職責原則。分別建立兩個類t1 t2，使t1完成職責p1功能，t...