軟件原則-單一職能原則

寫在前頭

在日常的軟件開發過程當中,咱們常常聽到軟件要符合單一原則, 開閉原則, 里氏替換原則, 接口隔離原則, 依賴倒置原則. 這些原則都是經過經驗教訓獲得的. 對於軟件開發中的大多數場景咱們都應該遵循這些原則, 固然在某些狀況下也要打破這些原則. 今天主要講講單一原則

定義

單一職能原則(single responsibility principle): 每個模塊或者類所對應的職責,應該對應系統若干功能中的某個單一功能, 同時對於該職責的封裝都應該經過這個類來完成 從定義中咱們能夠看到, 單一職能原則告訴咱們在日常的開發過程當中,咱們要儘量將模塊或類的做用保持單一.其實這個原則在不少方面都有所體現.好比如今流程的微服務, 某些系統就是經過業務功能來進行服務的劃分, 讓各自的服務作好各自的事情. 函數要保持近可能的功能單一. 雖然這個原則很簡單,可是在日常的開發過程當中,可能咱們仍然會觸犯. 因此在寫代碼前,設計方案時, 要提早考慮下單一職能原則.

實踐

記得以前在工做中, 須要查詢數據返回到界面, 由於後臺要處理的數據之間有依賴, 因此查詢的數據都在一個接口中進行了返回. 這樣致使後來這個接口特別難以維護,而且難以閱讀; 後臺嘗試優化界面邏輯, 將此接口按照界面不一樣的數據內容拆開, 拆開後每一個接口都只查詢界面對應的數據. 通過此重構以後, 接口變得較好的理解同時也下降了維護成本. 還有好比在咱們進行web開發時, 後端常常會涉及到不一樣的領域對象, 而領域對象的封裝建議根據功能單獨拆出一個類出來進行編寫. 經過封裝領域對象的方法儘量保持簡單. 這些都是我在平常開發中的一些體會. 除了這些, 咱們在平常開發工做中如何來避免違反單一職能原則呢? 有如下這些方法 有一個簡單的原則, 只須要牢記, 使代碼保持足夠的簡單

孤立變化

須要經常思考爲何代碼要這樣子寫, 代碼到底完成了什麼功能, 對於一些特別長的類和方法要格外注意. 注意將代碼中容易變化的點進行隔離

注意類之間的依賴

對於類之間,應該儘量的減小依賴, 若是一個類的構造函數較多, 可能就須要考慮進行對應的重構了. 能夠考慮採用工廠模式來解耦類的使用者和實現者之間的依賴. 也能夠採用依賴注入機制來減小類之間的依賴 PS: Spring就是採用依賴注入來達到類之間依賴的解耦

注意方法參數

方法參數要儘量少, 在代碼整潔之道中建議, 方法的參數不要超過三個. 若是方法參數過多,多是由於此方法作的工做太多, 能夠考慮重構方法, 或者考慮將方法參數封裝爲對應的領域對象 經過也要主要方法的命名, 若是方法的名稱過長, 每每表名方法內作了工做太多

儘早重構

在代碼的開發過程當中,若是發現有了更好的更簡明的方式要進行,要重構它. 這樣可以及早的發現問題. 若是須要作出改變,要果斷一些.固然這些內容都須要有對應的測試保證, 因此在代碼的編寫過程當中,最好有相應的單元測試以及集成測試