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

2021-07-09 03:48:48 字數 1560 閱讀 5195

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

單一職責原則(single responsibility principle, srp)：乙個類只負責乙個功能領


域中的相應職責，或者可以定義為：就乙個類而言，應該只有乙個引起它變化的原因。
單一職責原則告訴我們：乙個類不能太「累」！在軟體系統中，乙個類（大到模組，小到方法）承擔的職責越多，它被復用的可能性就越小，而且乙個類承擔的職責過多，就相當於將這些職責耦合在一起，當其中乙個職責變化時，可能會影響其他職責的運作，因此要將這些職責進行分離，將不同的職責封裝在不同的類中，即將不同的變化原因封裝在不同的類中，如果多個職責總是同時發生改變則可將它們封裝在同一類中。單一職責原則是實現高內聚、低耦合的指導方針，它是最簡單但又最難運用的原則，需要設計人員發現類的不同職責並將其分離，而發現類的多重職責需要設計人員具有較強的分析設計能力和相關實踐經驗。

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

——————————————————————————————————

sunny軟體公司開發人員針對某crm（customer relationship management，客戶關係管理）系統中客戶資訊圖形統計模組提出了如圖1所示初始設計方案：

在圖1中，customerdatachart類中的方法說明如下：getconnection()方法用於連線資料庫，findcustomers()用於查詢所有的客戶資訊，createchart()用於建立圖表，displaychart()用於顯示圖表。

現使用單一職責原則對其進行重構。

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

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


(2) customerdao：負責運算元據庫中的customer表，包含對customer表的增刪改查等方


法，如findcustomers()；


(3) customerdatachart：負責圖表的生成和顯示，包含方法createchart()和


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

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

晚 上在宿舍把webcast翻出來，聽了李建忠講的關於物件導向設計的幾天基本設計原則的課，半懂非懂聽了下來，聽完之後除了茫然還是茫然！也好，只有這樣才能知道自己所知甚淺，所學甚糙！革命遠未成功，吾須戒驕戒躁！ps 個人覺得李建忠講課水平一般，可能他是乙個非常好的程式設計師，但不是乙個好的講課員，大概...

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

單一職責原則是最簡單的物件導向設計原則，它用於控制類的粒度大小。單一職責原則定義如下 單一職責原則 single responsibility principle,srp 乙個類只負責乙個功能領域中的相應職責，或者可以定義為 就乙個類而言，應該只有乙個引起它變化的原因。單一職責原則告訴我們 乙個類不...

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

單一職責原則是最簡單的物件導向設計原則，它用於控制類的粒度大小。單一職責原則定義如下 單一職責原則 single responsibility principle,srp 乙個類只負責乙個功能領域中的相應職責，或者可以定義為 就乙個類而言，應該只有乙個引起它變化的原因。單一職責原則告訴我們 乙個類不...