整理于網路
1、遵循單一職責原則
函式是程式員的工具中最重要的抽象形式，它們能更多地被重復使用，你需要撰寫的代碼就越少，代碼也因此變得更可靠，較小的函式遵循單一職責原則更有可能被重復使用，
2、盡量減少共享狀態
你應該盡量減少函式之間的隱式共享狀態，無論它是檔案作用域的變數還是物件的成員欄位，這有利于明確要求把值作為引數，當能明確地顯示函式需要什么才可以產生所需的結果時，代碼會變得更容易理解和重用，
對此的一個推論是，在一個物件中，相對于成員變數，你更應該優先選擇靜態的無狀態變數 (static stateless variables)，
3、將副作用區域化
理想的副作用（例如：列印到控制臺、日志記錄、更改全域狀態、檔案系統操作等）應該被放置到單獨的模塊中，而不是散布在整個代碼里面，函式中的一些“副作用”功能往往違反了單一職責原則，
4、優先使用不變的物件
如果一個物件的狀態在其建構式中僅被設定一次，并且從不再次更改，則除錯會變得更加容易，因為只要構造正確就能保持有效，這也是降低軟體專案復雜性的最簡單方法之一，
5、介面高于類
接收介面的函式（或 C++ 中的模板引數和概念）比在類上運行的函式更具可重用性，點擊這里查看 6 大設計原則，
6、對模塊應用良好的原則
尋找機會將軟體專案分解成更小的模塊（例如庫和應用程式），以促進模塊級別的重用，對于模塊，應該遵循的一些關鍵原則是：
1.盡可能減少依賴
2.每個專案應該有一個明確的職責
3.不要重復自身
你應該努力使你的專案保持小巧和明確，
7、避免繼承
在面向物件編程中，繼承 —— 特別是和虛擬函式結合使用時，在可重用性方面往往是一條死胡同，我很少有成功的使用或撰寫多載類的庫的經歷，
8、將測驗作為設計和開發的一部分
我不是測驗驅動開發的堅定分子，但開始編碼時先撰寫測驗代碼會使得代碼十分自然地遵循許多指導原則，這也有助于盡早發現錯誤，不過要注意避免撰寫無用的測驗，良好的編碼實踐意味著更高級別的測驗（例如單元測驗中的集成測驗或特征測驗）在揭示缺陷方面更有效，
9、優先使用標準的庫
我經常看到更好版本的 std::vector或 std::string ，但這幾乎總是浪費時間和精力，一個明顯的事實是 —— 你正在為一個新的地方引入 bug，其他開發者也不太可能重用你的代碼，因為沒有被廣泛理解、支持和測驗，
10、避免撰寫新的代碼
這是每個程式員都應遵循的最重要的教誨：最好的代碼就是還沒寫的代碼，你寫的代碼越多，你將遇到的問題就越多，查找和修復錯誤就越困難，
在寫一行代碼之前先問一問自己，有沒有一個工具、函式或者庫已經實作了你所需要的功能？你真的需要自己實作這個功能，而不是呼叫一個已經存在的功能嗎？
你還知道別的設計原則嗎？歡迎留言！
推薦去我的博客閱讀更多：
1.Java JVM、集合、多執行緒、新特性系列教程
2.Spring MVC、Spring Boot、Spring Cloud 系列教程
3.Maven、Git、Eclipse、Intellij IDEA 系列工具教程
4.Java、后端、架構、阿里巴巴等大廠最新面試題
覺得不錯，別忘了點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/163253.html
標籤：Java
上一篇：JVM類加載機制