以下內容來自《Java設計模式》
1 單一職責原則
單一職責原則是最簡單的面向對象設計原則，它用於控制類的粒度大小。單一職責原則的定義如下：
單一職責原則：一個對象應該只包含單一的職責，並且該職責被完整地封裝在一個類中。
單一職責原則的另一種定義方式：就一個類而言，應該僅有一個引起它變化的原因。
在軟件系統中，一個類（大到模塊，小到方法）承擔的職責越多，它被複用的可能性越小，而且一個類承擔的責任過多，相當於將這些職責耦合在一起，當其中一個職責變化時，可能會影響其它職責的運作，因此要將這些職責進行分離，將不同的職責封裝在不同的類中，即將不同變化原因封裝在不同的類中，如果多個職責總是同時發生改變，則可將他們封裝在同一個類中。
單一職責原則是實現高內聚、低耦合的指導方針，它是最簡單但又最難運用的原則，需要設計人員發現類的不同職責並將其分離，而發現類的多重職責需要設計人員具有較強的分析設計能力和相關實踐經驗。
下面通過一個簡單實例來進一步分析單一職責原則。
2 單一職責原則實例
某軟件公司開發人員針對客戶關係管理系統中的客戶信息圖形統計模塊提出瞭如圖2-1所示的初始設計方案。在CustomerDataChart類的方法中，getConnection()方法用於連接數據庫，findCustomers()用於查詢所有的客戶信息，createChart()用於創建圖表，displayChart()用於顯示圖表。
現在使用單一原則對其進行重構。
在圖2-1中，CustomerDataChart類承擔了太多的職責，既包含與數據庫相關的方法，又包含與圖表生成和顯示相關的方法。如果在其他類中也需要連接數據庫或者使用findCustomer()方法查詢客戶信息，則難以實現代碼的重用。無論是修改數據庫連接方式還是修改圖表顯示方式都需要修改該類，它擁有不止一個引起它變化的原因，違背了單一職責原則。因此需要對該類進行拆分，使其滿足單一職責原則，CustomerDataChart類可拆分爲以下3個類。
-
DBUtil：負責連接數據庫，包含數據庫連接方法getConnection()； -
CustomerDAO：負責操作數據庫中的Customer表，包含對Customer表的增、刪、改、查等方法，例如findCustomers() -
CustomerDataChart：負責圖表的生成和顯示，包含createChart()和displayChart()方法。
使用單一職責原則重構後的結構圖如圖2-2所示：
