面向對象設計原則之單一職責原則

單一職責原則是最簡單的面向對象設計原則，它用於控制類的粒度大小。單一職責原則定義以下：

單一職責原則(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  重構後的結構圖