單一職責

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

單一職責原則是實現高內聚、低耦合的指導方針，它是最簡單但又最難運用的原則

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

設計原則很重要的一點就是簡單，單一職責，也就是我們經常所說的專人干專事。

一個單元（一個類、函數或者微服務）應該有且只有一個職責。無論如何，一個微服務不應該包含多於一個的職責。職責單一的後果之一就是職責單位（微服務，類，接口，函數）的數量劇增。據說Amazon,Netflix這些採用微服務架構的網站一個小功能就會調用幾十上百個微服務。但是相較於每個函數都是多個業務邏輯或職責功能的混合體的情況，維護成本還是低很多的。 SRP中的“單一職責”是個比較模糊的概念。對於函數，它可能指單一的功能，不涉及複雜邏輯；但對於類或者接口，它可能是指對單一對象的操作，也可能是指對該對象單一屬性的操作。總而言之，單一職責原則就是為了讓代碼邏輯更加清晰，可維護性更好，定位問題更快的一種設計原則。

什麼是高內聚低耦合？

這犀利的措辭一看就是來自開發界的術語。高內聚是說一個功能模塊最好僅完成一個獨立的子功能並且完成的很好。低耦合是指模塊與模塊之間盡量獨立／聯繫少／接口簡單。

這個原則出現的背景是為了讓程序“可復用／可擴展／夠靈活／可維護”。干過一陣子產品的人對這幾個詞應該都不陌生。對於程序設計者來說，這幾個詞是十分重要的，不亞於產品經理口中的“用戶體驗”（原則or擋箭牌）。

優點

單一職責的優點如下:

•類的複雜性降低，實現什麼職責都有清晰明確的定義。•可讀性提高，複雜性降低。•可維護性提高，可讀性提高。•變更引起的風險降低，變更是必不可少的，如果接口的單一職責做得好，一個接口修改只對相應的實現類有影響，對其他的接口無影響，這對系統的擴展性、維護性都有非常大的幫助。

記得在三字經裡邊有這樣一段 教之道，貴以專（出自三字經） 說的就是無論學習還是構建團隊，最重要的是專才，而不是全才。就好比一個足球隊，如果都是前鋒或者都是後衛，那麼這樣的球隊一定不能出成績，反而是將各個位置上的人進行統一協調，根據分工不同，共同協作，形成1+1>2的效果，那麼這樣的團隊就非常容易出成績。

有很多公司為了趕進度，經常會招聘一些所謂的全能型人才，但是這種人往往專業的程度不夠，當遇到某些棘手的問題的時候，往往不能夠非常快速的解決問題。從而導致最終交付的質量較差。

單一職責的目的

實施單一職責的目的如下：

•以類來隔離需求功能點，這樣當一個點的需求發生變化的時候，不會影響別的類的邏輯，這個和設計模式中的開閉原則類似，對於擴展持開放態度，對於修改持關閉態度。•是一個原子模塊級的粒度，至於原子的粒度到底是什麼樣的，應該因業務而異，設計的過程中同時考慮業務的擴展，所以這就要求在設計的過程中，必須有業務專家共同參与，共同規避風險。•粒度小，靈活，復用性強，方便更高一級別的抽象。

每個微服務單獨運行在獨立的進程中，能夠實現松耦合，並且獨立部署。

如何做

分3步：

1.把一個具體的問題抽象成一類問題；

2.根據用戶體驗流程劃分功能模塊；

3.針對每個功能設計封閉的解決方案。

最佳實踐

在實際工作中，有一個經常會用到的設計模式，DAO模式，又叫數據訪問對象，裏面定義了數據庫中表的增、刪、改、查操作，按照單一職責原則，為什麼不把增、刪、改、查分別定義成四種接口？這是因為數據庫的表操作，基本上就是這四種類型，不可能變化，所以沒有必要分開定義，反而經常變化的是數據庫的表結構，表結構一變，這四種操作都要跟着變。所以通常我們會針對一張表實現一個DAO，一張表就代表一種類型的職責。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計最專業,超強功能平台可客製化