單一職責原則是最簡單的面向對象設計原則，它用於控制類的粒度大小。單一職責原則定義如下：
單一職責原則(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所示：
