首先是定義
單一職責原則：一個類應該只有一個發生變化的原因
英文名叫Single Responsibility Principle，以下簡稱爲SRP
下面我們從三本著作中去解讀這個單一職責
這三本著作分別是《深入淺出面向對象分析與設計》、《設計模式解析》和《敏捷開發：原則、模式與實踐》。
深入淺出面向對象分析與設計
首先他對SRP的解讀稍有不同：
單一職責原則：系統裏的每一個對象應該具有單一職責，所有對象的服務都應該聚焦在實現該職責上。
且他認爲
內聚性是SRP的另一個名稱。如果你的類是高內聚的，就表示你在正確的使用SRP。
爲什麼要強調他這裏說的內聚性呢？因爲在《敏捷》書中，他認爲如果類的接口不是內聚的，那麼就違反了接口隔離原則
（在百度百科裏，他認爲單一職責是基於內聚性提出的。圖如下）
在最後他提出了一個判斷是否是單一職責的辦法：
寫下一個式子：
the itself,其中第一個單詞寫類名，第二個單詞寫方法名，如果有參數的話在方法後跟上參數
我們舉這樣一個例子，調製調解器，就是光貓，可以撥號掛斷，發數據和接收數據。
用《深入淺出》裏的方法這個符合單一職責模式。但是在《敏捷》裏就不符合了，這裏在後面講。
下面來看《設計模式解析》
設計模式解析
他將對象看做是具有責任的東西。每個對象包含一組職責，這個在之前如何理解一個類——單一職責原則中已經說了很多，這裏不再贅述
最後一個是要將《敏捷》書
敏捷開發：原則、模式與實踐
書中也說了來自於內聚性，但是在他的理解裏，上述光貓的例子是違反SRP的。
他認爲撥號和掛斷屬於連接管理，接受和發送屬於數據通信。
我們把前者認爲是A職責，後者是B職責，這兩種職責是否應該被分開取決於兩者是否經常同時變化。
如果在A職責出現變動時，B職責也要同時變動，那麼兩個可以不用分開，否則的話就需要被分開。
- 假設此時二者是同時變化的，而分開了
那麼帶來的影響是：我在修改A職責所在的類時還要去審查B職責所在類的正確改動，顯然是不好的。 - 假設此時二者是非同時變化的，沒有分開
那麼帶來的影響是：（書中所說）其他不需要變化的方法需要重新部署編譯，會增加部署的次數。另一方面我覺得是因爲二者可以獨立變化。
最終的解決方案是將兩個獨立變化的職責分到了連接管理類和數據通信類，然後新建一個光貓類組合這兩個類，外部依賴光貓類去調用。![圖片描述]()
提到了另一個例子是MVC
如Person類，從某種角度來看，Person的持久化（dao層）職責和業務（Service）職責都屬於Person的職責，但是顯然是不能放在一起的，原因是持久化層幾乎不會變化，而業務層複雜多變改動大。持久化層隔離開後複用性高。
最後文末提到了外觀模式和代理模式，這兩個模式可以用於分離職責。
PS《敏捷》中提及的是否同步變化在其他兩處沒有特別強調，相對寬鬆，很多地方沒有獨立的講接口隔離原則。
