單一職責原則是物件導向設計原則中的一條舉個簡單的例子，假設，在工廠中，一款產品從無到有需要經過10種機器。我們是讓10個人，每個人拿著原材料從第一台操作到第十臺比較快，還是每個機器有乙個單獨的人專門處理這台機器比較快。答案是顯而易見的。
因此工廠在實現分工後，效率有了大幅度的提高。這就是企業管理中的分工，而在物件導向設計裡，它被叫做單一職責原則（single pesponsibility principle, srp）。
在《敏捷軟體開發》中，把「職責」定義為「變化的原因」，也就是說，乙個類應該只有乙個引起他變化的原因。這是乙個最簡單，最容易理解，但是卻最不容易做到的乙個設計原則。說的簡單一點，就是怎樣設計類以及類的方法界定的問題。這種問題是很普遍的，例如在mvc的框架匯中，很多人疑惑對於表單插入資料庫字段過濾與安全檢查應該放在m層還是c層處理，這類問題就可以歸到單一職責的範圍。
再比如在職員類中，將工程師、銷售人員、銷售經理等等都放在職員類裡考慮，其結果將會非常混亂。在這個假設下，職員類裡的每個方法（例如發工資）都要用if else 判斷是那種職員型別，從類結構上來說會十分臃腫，並且任何職員型別，不論哪一種發生需求變化，都會改變職員類，這是我們不願意看到的。
從上面的描述中可以看出，單一職責有兩個含義：乙個是避免相同的職責分散到不同的類中，另乙個是避免乙個類承擔太多的職責。
為什麼要遵守單一職責原則呢？
（1）可以減少類之間的耦合
（2）提高類的復用性
以資料持久層為例，所謂的資料持久層就是指資料庫操作。如果是乙個複雜的系統，那麼就可能涉及到多種資料庫的相互讀寫等，這時就需要資料持久層支援多種資料庫。那應該怎麼做呢？定義多個操作類嗎？想法很接近了，在進一步，就是工廠模式。
命令模式、**模式也是單一職責原則的體現。
單一職責原則不只是對類設計有意義，對以模組、子系統為單位的系統架構設計同樣有意義。
模組、子系統也應該僅有乙個引起他變化的原因，如mvc所倡導的各個層之間的互相分離其實就是單一職責原則在系統總體設計中的應用。
下面的圖是ci框架的流程圖
單一職責原則是最簡單的原則，也是最難做好的原則。我們很自然的將職責連線在一起，所以找到並且分開這些職責是軟體設計需要達到的目的。
一些簡單應該遵循的做法是：
根據業務流程，把業務物件提煉出來。
如果業務鏈路太過複雜，那麼將業務物件分離為多個單一業務物件。當業務鏈標準化後，對業務物件的內部情況做進一步處理。把第一次標準化視為最高層抽象，第二次視為次高層抽象，以此類推，直到「恰如其分」的設計層次。
職責的分類要注意。
有業務職責，還要有脫離業務的抽象職責，從認識業務到抽象演算法是乙個層層遞進的過程。就好比命令模式中的顧客，服務員和廚師的職責，作為設計師的你需要提前規劃好各自的職責，既要防止越俎代庖，也要防止互相推諉。
單一職責原則
定義 不要存在多於乙個導致類變更的原因。通俗的說，即乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 遵循單一職責原則。分別建立兩個類t1 t2，使t1完成職責p1功能，t...
單一職責原則
單一職責原則 乙個類，只有乙個引起它變化的原因。應該只有乙個職責。每乙個職責都是變化的乙個軸線，如果乙個類有乙個以上的職責，這些職責就耦合在了一起。這會導致脆弱的設計。當乙個職責發生變化時，可能會影響其它的職責。另外，多個職責耦合在一起，會影響復用性。例如 要實現邏輯和介面的分離。對於user類，裡...
單一職責原則
問題由來 一心二用，效率降低 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 專注做某件事情 遵循單一職責原則。分別建立兩個類t1 t2，使t1完成職責p1功能，t2完成職責p2功能。這樣，當修改類t1...