設計模式筆記:單一職責原則(SRP, Single Responsibility Principle)


1. 單一職責原則核心思想

  一個類應該有且只有一個變化的原因。

2. 為什么引入單一職責原則

  單一職責原則將不同的職責分離到單獨的類,每一個職責都是一個變化的中心。

  在SRP中,把職責定義為變化的原因。

  當需求變化時,將通過更改職責相關的類來體現。如果一個類擁有多於一個的職責,則多個職責耦合在一起,會有多於一個原因來導致這個類發生變化。一個職責的變化可能會影響到其他的職責,另外,把多個職責耦合在一起,影響復用性。

3. 單一職責原則的優點

(1)降低類的復雜度;
(2)提高類的可讀性,提高系統的可維護性;
(3)降低變更引起的風險(降低對其他功能的影響)。

4. 單一職責原則實現

  單一職責原則關鍵點:要求接口的職責單一,從而實現該接口的類的職責單一。

  

        Socket實現類的職責分離

  IDataChannel職責:數據通信

  IConnection職責:連接管理

  SocketImplementation:兩個職責耦合,這不是所希望的,但或許是必要的。

5. 單一職責原則重構

  業務規則和持久化兩個職責應該分開:業務規則往往會頻繁變化,而持久化的方式卻不會如此頻繁的變化,並且變化的原因完全不同。

  違反SRP原則的重構可采取設計模式:外觀模式(Facade)代理模式(Proxy)數據訪問對象(DAO)

6. 使用單一職責原則的注意點

(1)單一職責最難划分的是職責。
(2)單一職責原則提出標准:用職責和變化原因來衡量接口或類設計的是否優良,但是職責和變化原因都是不可度量的,因項目、環境而異。
(3)接口一定要做到單一職責,類的設計盡量做到只有一個原因引起變化。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM