1. 單一職責原則核心思想
一個類應該有且只有一個變化的原因。
2. 為什麼引入單一職責原則
單一職責原則將不同的職責分離到單獨的類，每一個職責都是一個變化的中心。
在SRP中，把職責定義為變化的原因。
當需求變化時，將通過更改職責相關的類來體現。如果一個類擁有多於一個的職責，則多個職責耦合在一起，會有多於一個原因來導致這個類發生變化。一個職責的變化可能會影響到其他的職責，另外，把多個職責耦合在一起，影響複用性。
3. 單一職責原則的優點
（1）降低類的複雜度；
（2）提高類的可讀性，提高系統的可維護性；
（3）降低變更引起的風險（降低對其他功能的影響）。
4. 單一職責原則實現
單一職責原則關鍵點：要求介面的職責單一，從而實現該介面的類的職責單一。
Socket實現類的職責分離
IDataChannel職責：資料通訊
IConnection職責：連線管理
SocketImplementation：兩個職責耦合，這不是所希望的，但或許是必要的。
5. 單一職責原則重構
業務規則和持久化兩個職責應該分開：業務規則往往會頻繁變化，而持久化的方式卻不會如此頻繁的變化，並且變化的原因完全不同。
違反SRP原則的重構可採取設計模式：外觀模式（Facade）、代理模式（Proxy）或資料訪問物件（DAO）。
6. 使用單一職責原則的注意點
（1）單一職責最難劃分的是職責。
（2）單一職責原則提出標準：用職責和變化原因來衡量介面或類設計的是否優良，但是職責和變化原因都是不可度量的，因專案、環境而異。
（3）介面一定要做到單一職責，類的設計儘量做到只有一個原因引起變化。