DRY原則
DRY 原則，它的英文描述為：Don’t Repeat Yourself，中文直譯為：不要重復自己，也可以理解為：不要寫重復的代碼，
我們從實作邏輯重復、功能語意重復和代碼執行重復，這三種代碼重復來說明DRY原則，
實作邏輯重復
例如有兩個函式isValidUserName() 和 isValidPassword() ，它們的代碼其實是一樣的，這個時候如果我們將其合并成一個函式，雖然代碼量減少了，也沒有重復代碼，但卻違反了DRY原則，從代碼實作邏輯上看起來是重復的，但是從語意上并不重復，所謂“語意不重復”指的是：從功能上來看，這兩個函式干的是完全不重復的兩件事情，一個是校驗用戶名，另一個是校驗密碼，其實兩個代碼是做不同的事情，如果因為代碼一樣合并了，后面由于用戶名或者密碼校驗邏輯改變，都將使函式再次拆分成兩個函式，
功能語意重復
現在我們再來看另外一個例子，在同一個專案代碼中有下面兩個函式：isValidIp() 和 checkIfIpValid()，盡管兩個函式的命名不同，實作邏輯不同，但功能是相同的，都是用來判定 IP 地址是否合法的，盡管兩段代碼的實作邏輯不重復，但語意重復，也就是功能重復，我們認為它違反了 DRY 原則，而且如果兩個函式功能一樣同時存在，且都被呼叫，這時一個程式員如果只知道一個函式，并修改了其函式邏輯，那么會導致另一個函式的邏輯并沒有改變，偶從遺漏修改，
代碼執行重復
這段代碼，既沒有邏輯重復，也沒有語意重復，但仍然違反了 DRY 原則，這是因為代碼中存在“執行重復”，
重復執行最明顯的一個地方，就是在 login() 函式中，email 的校驗邏輯被執行了兩次，一次是在呼叫 checkIfUserExisted() 函式的時候，另一次是呼叫 getUserByEmail() 函式的時候，這個問題解決起來比較簡單，我們只需要將校驗邏輯從 UserRepo 中移除，統一放到 UserService 中就可以了，
除此之外，代碼中還有一處比較隱蔽的執行重復，不知道你發現了沒有？實際上，login() 函式并不需要呼叫 checkIfUserExisted() 函式，只需要呼叫一次 getUserByEmail() 函式，從資料庫中獲取到用戶的 email、password 等資訊，然后跟用戶輸入的 email、password 資訊做對比，依次判斷是否登錄成功，實際上，這樣的優化是很有必要的，因為 checkIfUserExisted() 函式和 getUserByEmail() 函式都需要查詢資料庫，而資料庫這類的 I/O 操作是比較耗時的，我們在寫代碼的時候，應當盡量減少這類 I/O 操作，
如何提高代碼可復用性
提高代碼可復用性的一些方法，有以下 7 點，
- 減少代碼耦合
- 滿足單一職責原則
- 模塊化
- 業務與非業務邏輯分離
- 通用代碼下沉
- 繼承、多型、抽象、封裝
- 應用模板等設計模式
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/498976.html
標籤：設計模式
上一篇：嵌入式軟體架構設計-程式分層