1.2　設計模式的原則

1.2.1　單一職責原則

引用百度詞條對單一職責原則的定義：“單一職責原則（Single Responsibility Principle，SRP）又稱單一功能原則，面向對象五個基本原則（SOLID）之一。它規定一個類應該只有一個發生變化的原因。該原則是Robert C. Martin于《敏捷軟件開發：原則、模式與實踐》一書中給出的。Martin表示此原則是基于Tom DeMarco和Meilir Page-Jones的著作中的內聚性原則發展出的?！?/p>

單一職責原則，強調的是職責的分離，一個類，只需要負責一種職責即可，一個類發生變化的原因，必然是所負責的職責發生變化。這聽起來很抽象，干澀的文字描述可能會讓經驗稍淺的讀者產生一定的困惑，可實際上，從我們接觸代碼的那一刻起，已經時時刻刻地在遵守單一職責原則。

·　main函數所在的類，作為程序的啟動入口，職責單一。

·　SpringBoot框架的啟動類是單一職責原則最完美的寫照。

·　我們創建的utils工具類，對日期的處理一般會封裝到一個DateUtils.java中，職責單一。即便我們將所有的工具類方法封裝到一個統一的CommonUtils.java中，也依然遵循了單一職責原則，因為它的職責就是工具。

·　大家眾所周知的MVC框架，提倡將接入層Controller、服務層Service、持久層DAO分別進行實現，劃分不同的職責，也遵循了單一職責原則。

……

單一職責原則，是一個備受爭議的原則，也是設計模式最為基礎的原則。備受爭議的原因是，每個人對職責劃分的看法不一樣，不同項目需求所面臨的挑戰和劃分方式不一樣。我們以一個簡單的“用戶注冊和用戶登錄”需求為例，展開一場討論，相信這個需求對讀者來說是非常簡單的，很快就能書寫以下代碼。

這是一個非常完美的設計，UserService類完全遵循了單一職責原則，不管是register注冊功能還是login登錄功能，都屬于“用戶操作”的相關職責，簡單的注冊和登錄功能，用粗粒度的“用戶操作”職責進行了正確的劃分。

然而，如果登錄功能需要滿足多種第三方賬號授權登錄，注冊功能需要進行短信、郵箱等動態碼驗證，金融相關軟件還需要進行身份證驗證和人臉識別等一系列附加功能，我們可能就要考慮將登錄功能和注冊功能以更加細粒度的職責進行劃分。

（1）登錄功能單獨劃分，提供默認登錄方式（擁有本站賬號的用戶）和第三方賬號的驗證及登錄功能。

（2）注冊功能單獨劃分，分為注冊功能以及注冊過程中所需要的相關驗證功能如下。

這樣的設計也是非常正確的，隨著業務的復雜程度越來越高，每一個細粒度的職責都可能擁有非常復雜的邏輯，那么我們就要考慮是否可以按照項目需求進行更加細粒度的職責拆分，從而保證單一職責原則下的低耦合度。當然，部分讀者會認為，是否可以將“手機驗證功能”和“郵箱驗證功能”再次進行單一職責的劃分？當然可以，但是要避免過度的職責拆分，要根據項目需求的復雜程度進行合理的規劃。

最后，我想對廣大讀者說的是，單一職責原則的劃分沒有正確與錯誤之分，每個開發者都有自己的考量角度和劃分方式。一切都應該以項目實際情況為出發點進行設計，因地制宜才是我們真正需要遵守的原則。