單一職能原則
軟體開發過程中常說的高內聚低耦合就是單一職責的前身，那麼單一職責到底如何體現呢，下面通過一段**來解釋說明
public class animal
//過載不贅述
……}public class client
那麼我們可以想到增加乙個列舉作為引數，再類中進行判斷，如果傳入魚類（不管是鯊魚，鯨魚還是海豚）就輸出「游在水裡」不就ok了麼。這樣做當然是沒有問題的，但是，再增加鳥類呢，是不是就要修改列舉型別和修改animal類的move方法了呢？這就違背了開放關閉原則,將來在出現其他類中的生物例項化的時候會影響到這個類的變化，這樣就是因為animal類的職責不單一導致的。
建立乙個介面，ianimal，宣告move方法，再建立子類，person，fish，bird等類繼承ianimal，每個類都實現自己的move行為，就算將來出現了新物種，只要增加新的類就好了，不會影響原來的任何類和行為。
如何定義單一職責：在各個公司、專案組經常聽見關於單一職責的問題爭論不休，爭論的內容無非就是***類的職責是否單一，該職責還能夠拆分或者是***類和***類可以合併，減少**量和維護成本，雖然違反了單一職責，但是這個不會更複雜了，可以這樣合併。
討論的問題1：***類是否職責單一
這是很難界定的問題，想要確定，那麼就先要確定專案的大小和功能的劃分粒度以及類的最小粒度，只有明確了這三點，才能確定***類是否職責單一。
推薦方法：確定專案大小可以根據**量或者實體類的數量進行確定。將專案中遇到的所有名詞都羅列出來，進行篩選，得到有效核心的名詞，如果這些名詞包含內容很多，可以繼續拆分，直到所有人（大部分）舉手表決認為已經不需要拆分。次級別就是最小粒度了，非核心名詞可以採取次一級別的粒度進行劃分。
比如：乙個鐵路專案中的名詞：火車，這個名詞明顯還需要繼續拆分，因為不同的火車的**，維護甚至是軌道都不同，區別太大，而且將來可能會出現磁懸浮火車，空中火車或者出現懷舊的特慢火車。
討論的問題2：是否可以違背單一職責原則
關於這個問題我不再總結，網上有很多很到位的總結，引用一下
ａ.只有邏輯足夠簡單，才可以在**級別上違背ｓｒｐ；ｂ.只有類中方法數量足夠少，才可以在方法級別上違背ｓｒｐ；引用位址
單一職責原則
定義 不要存在多於乙個導致類變更的原因。通俗的說，即乙個類只負責一項職責。問題由來 類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...