Agile Principles, Patterns, and Practices in C# 無瑕的程式碼 敏捷完整篇 第8章 SRP:單一職責原則

        第八章內容是SRP(單一職責原則)，作者有提到要不要分離也要看專案情況，並不是一定分越細越好。

內聚性定義為：「一個模組的組成元素之間的功能相關性」

SRP:單一職責原則

一個類別應該只有一個發生變化的原因。

圖8-1 是多職責的範例

Rectangle類別有兩個方法 draw 把矩形畫在螢幕上與 area計算矩形面積。

有兩個不同的應用程式使用Rectangle類別，設計違反單一職責原則。若是GraphicalApplication改變導致Rectangle類別跟著改變，會造成ComputationalGeometryApplication也要重新建置、測試與部署。

圖8-2是圖8-1改善之後的範例，符合單一職責原則。

定義職責

職責定義為「變化的原因」。

Listing 8-1 介面的4個函式確實都是數據機具備的功能。實際上介面有兩個職責連接管理與資料通訊。

圖8-3 將原有的介面分離成兩個介面，符合單一職責原則。

作者指出要不要分離Listing 8-1 Modem介面要看專案實際情況，如果應用程式變化都會導致兩個職責同時變化，就不必分開Modem介面。

分離耦合的職責

圖8-3 ModemImplementation類別繼承 DataChannel介面與Connection介面

持久化 (Persistence)

圖8-4 展示一種違反SRP常見的情況，Employee類別包含業務規則與對持久化的控制

驅動程式開發會在設計的時候分離這兩個職責。

FACADE(外觀模式)、DAO(資料存取物件)或PROXY(代理模式)重構可分離職責。

總結

SRP最簡單也最難應用。

軟體設計要發現職責，並且把職責相互分離。