物件導向設計原則之單一職責原則

      單一職責原則是最簡單的物件導向設計原則，它用於控制類的粒度大小。單一職責原則定義如下：

單一職責原則(Single Responsibility Principle, SRP)：一個類只負責一個功能領域中的相應職責，或者可以定義為：就一個類而言，應該只有一個引起它變化的原因。

      單一職責原則告訴我們：一個類不能太“累”！在軟體系統中，一個類（大到模組，小到方法）承擔的職責越多，它被複用的可能性就越小，而且一個類承擔的職責過多，就相當於將這些職責耦合在一起，當其中一個職責變化時，可能會影響其他職責的運作，因此要將這些職責進行分離，將不同的職責封裝在不同的類中，即將不同的變化原因封裝在不同的類中，如果多個職責總是同時發生改變則可將它們封裝在同一類中。

      單一職責原則是實現高內聚、低耦合的指導方針，它是最簡單但又最難運用的原則，需要設計人員發現類的不同職責並將其分離，而發現類的多重職責需要設計人員具有較強的分析設計能力和相關實踐經驗。

      下面通過一個簡單例項來進一步分析單一職責原則：

Sunny軟體公司開發人員針對某CRM（Customer Relationship  Management，客戶關係管理）系統中客戶資訊圖形統計模組提出瞭如圖1所示初始設計方案： 圖1  初始設計方案結構圖 在圖1中，CustomerDataChart類中的方法說明如下：getConnection()方法用於連線資料庫，findCustomers()用於查詢所有的客戶資訊，createChart()用於建立圖表，displayChart()用於顯示圖表。 現使用單一職責原則對其進行重構。

      在圖1中，CustomerDataChart類承擔了太多的職責，既包含與資料庫相關的方法，又包含與圖表生成和顯示相關的方法。如果在其他類中也需要連線資料庫或者使用findCustomers()方法查詢客戶資訊，則難以實現程式碼的重用。無論是修改資料庫連線方式還是修改圖表顯示方式都需要修改該類，它不止一個引起它變化的原因，違背了單一職責原則。因此需要對該類進行拆分，使其滿足單一職責原則，類CustomerDataChart可拆分為如下三個類：

      (1) DBUtil：負責連線資料庫，包含資料庫連線方法getConnection()；

      (2) CustomerDAO：負責運算元據庫中的Customer表，包含對Customer表的增刪改查等方法，如findCustomers()；

      (3) CustomerDataChart：負責圖表的生成和顯示，包含方法createChart()和displayChart()。

      使用單一職責原則重構後的結構如圖2所示：

圖2  重構後的結構圖

【作者：劉偉  http://blog.csdn.net/lovelion】