單一職責原則 （Single Responsibility Principle, SRP） 單一職責原則在設計模式中常被定義為“一個類應該只有一個發生變化的原因”，若我們有兩個動機去改寫一個方法，那這個方法就有兩個職責。實際開發過程，修改代碼本身就存在風險，特別是兩個職責耦合在一起有依賴關係的時候， ...
單一職責原則 （Single Responsibility Principle, SRP）
單一職責原則在設計模式中常被定義為“一個類應該只有一個發生變化的原因”，若我們有兩個動機去改寫一個方法，那這個方法就有兩個職責。實際開發過程，修改代碼本身就存在風險，特別是兩個職責耦合在一起有依賴關係的時候，一個職責的變化可能對整個邏輯造成意想不到的破壞，這種耦合性得到的是低內聚和脆弱的設計。
SRP原則體現為：一個對象（方法）只做一件事
何時應該分離職責
SRP 原則是所有原則中最簡單也是最難正確運用的原則之一。 要明確的是，並不是所有的職責都應該一一分離。
一方面，如果隨著需求的變化，有兩個職責總是同時變化，那就不必分離他們。比如在 ajax 請求的時候，創建 xhr 對象和發送 xhr 請求幾乎總是在一起的，那麼創建 xhr 對象的職責和發送 xhr 請求的職責就沒有必要分開。
另一方面，職責的變化軸線僅當它們確定會發生變化時才具有意義，即使兩個職責已經被耦 合在一起，但它們還沒有發生改變的徵兆，那麼也許沒有必要主動分離它們，在代碼需要重構的 時候再進行分離也不遲。
通常我們習慣把相關的行為放在一起，所以實際開發過程中，看似簡單的按職責分離其實也沒那麼容易，這時我們就需要在方便性和穩定性中做好取捨，比如jquery的attr方法，既可以用來賦值，又可以用來取值，從開發維護的角度來講，這裡違反SRP原則存在一定的維護成本，但卻簡化了用戶的使用。在業務上下文強耦合的情況下，分離可能並不是更好的選擇，這個時候就該考慮分離的必要性。職責分離並沒有一定的標準，無需糾結，具體看開發時的業務場景進行合理選擇就好。
優點
降低單個類或對象的複雜度，更細粒度地去管理對象，有助於代碼的復用。
缺點
增加編寫代碼的複雜度，當我們按照職責來分解對象之後，實際上也增大了對象之間相互聯繫的難度。
