設計原則在實際開發中的應用
什么是設計原則？
? 我們實際開發當中，經常會思考，"代碼怎么寫才是更好"這個問題，其實這個問題在有程式員這個作業的時候就已經出現了，前輩們也一直在思考，慢慢的提出了一些"好代碼"的形容詞，比如說：可擴展性，可讀性，可維護性等，并且總結出了一些好代碼的特點，這些特點就是現在所說的設計原則，也就是說我們遵從設計原則目的是開發出擴展性高，可讀性好，可維護性強的代碼，
設計原則有哪些
1. 開閉原則
? 對于擴展開放，對于修改關閉，這里是一個顆粒度的問題，一個動作到底是修改的還是擴展的，從不同的角度能得到不同的結果，這個原則是我們平時開發最常使用的，我們接手其他同事的代碼，當有新需求變動時，都是在原代碼的基礎上進行改動的，個人認為，修改的源代碼不影響原業務，并且是易于測驗的都是遵守開閉原則，
2. 單一職能原則
? 同樣的，單一職能原則也是有顆粒度的，實際開發中有同事會把一個業務的代碼都寫到一個類的一個方法當中，認為這個方法完成了這件事，他是單一職能的，但是一件事也可以拆分成很多個小事，每個小事也都是單一職能，這樣看原來的一件事就不是單一職責了，所以在實際開發當中，需要我們合理的去拆分業務，
3. 里氏替換原則
? 里氏替換原則是面向物件當中特有的，它涉及到了父子類的關系，所有的父類都可以用子類去替換，并且保證原有程式的邏輯行為不變，并且正確性不遭受破壞，就是里氏替換原則，
4. 最小知識原則（迪米特法則）
? 最小知識原則在實際開發當中經常違反的，比如說a專案當中用了一個HttpUtil的工具類（一個開源的jar包），b專案是從a專案遷移過來但是不需要用到httpUtil的工具類，我們一般都不會洗掉這個jar包，其實此時就是違反了最小知識原則，還有就是在搭建專案的時候我們習慣把一些常用的東西都一次性匯入進來，其實應該采用需要用什么匯入什么，這樣才是符合迪米特法則的，
5. 介面隔離原則
? 介面隔離原則指的是客戶端不應該強迫依賴它不需要的介面，"介面"這個詞，可以從不同的角度理解，比如微服務中的介面，如果a服務開放出來的介面在b服務中只呼叫了部分介面，那么此時應該將a服務中的介面隔離開來，讓b服務只能看到自己需要的介面，介面隔離原則和單一職能原則有點類似，只是觀察的角度或者說側重的角度不同，他更加注重于介面的設計，
6. 依賴倒置原則
? 依賴倒置原則就是讓框架幫助我們去控制流程，而不是程式員去控制流程，spring框架就是典型的依賴倒置原則的框架，
7. DRY原則
? don’t repeat yourself，不要重復自己，也就是不要寫重復的代碼，注意代碼是為了實作業務，如果是不同的業務即使代碼重復了，也是不違反DRY原則的，不要過分的去抽象剝離代碼，
如何寫出符合原則的代碼
? 沒有人能一次性寫出完美的代碼，初次書寫只能是大體符合，只有不斷的去重構，才能寫出更符合原則的代碼，重構并不是說專案重新搭建，一點一滴的優化都叫重構，甚至于將錯誤的注釋洗掉，并修改成好的注釋都是重構，重構是隨時隨刻的在進行的，如果一旦有稍微大一點的改動，都需要書寫單元測驗，不然的后果可能是災難性的，
如何撰寫單元測驗
? 實際開發當中，寫單元測驗的人并不多，但是寫單元測驗絕對是一個好的習慣，這將決定著你代碼是否能越寫越好，目前階段我個人認為只有易于測驗的代碼才能稱得上是好代碼，因為接受過幾個別人的代碼，每次再修改時都要補上基本的單元測驗，單元測驗也有不同的顆粒度，1.正常的資料邏輯，驗證單元測驗是否能通過，2. 邊界值的單元測驗，基本上做到第一點就可以了，如果能覆寫全邊界值的單元測驗，那只能說是優秀，測驗不需要來給你提bug了，甚至你的公司已經不需要測驗崗位了，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/5789.html
標籤：其他
上一篇：程式員的悲哀是什么？