Java 程序員應在2019年學習的10條面向對象（OOP）設計原則

面向對象的設計原則 是 OOP 編程的核心，可是我看到大多數 Java 程序員都在追求諸如 Singleton 模式，Decorator 模式或 O​​bserver 模式之類的設計模式，而對學習面向對象的分析和設計沒有給予足夠的重視。瞭解諸如抽象，封裝，多態和繼承之類的面向對象程序設計的基礎很重要。可是，與此同時，瞭解面向對象的設計原則也一樣重要。它們將幫助您建立簡潔的模塊化設計，未來能夠輕鬆進行測試，調試和維護。

我常常見過各類經驗水平的 Java 程序員和開發人員，他們要麼從未據說過這些 OOP 和 SOLID 設計原理，要麼根本不知道特定設計原理能夠提供什麼好處以及如何將這些設計原理應用於編碼中。

爲了發揮本身的做用，我已經寫下了全部重要的面向對象設計原則，並將其放在此處以供快速參考。這些至少會讓您對它們是什麼以及它們提供的好處有所瞭解。

面向程序員的10個面向對象和SOLID設計原則

儘管學習任何設計原理或模式的最佳方法是一個真實的示例，並瞭解違反該設計原理的後果，但本文的主題是爲 Java 程序員介紹面向對象的設計原理。

1.DRY (Don't repeat yourself)

咱們的第一個面向對象的設計原則是 DRY，顧名思義，DRY（不要重複造輪子）意味着不要編寫重複的代碼，而是使用Abstraction 在一個地方抽象常見的東西。若是您有兩個以上的重複代碼塊，請考慮使其成爲一種單獨的方法，或者若是您屢次使用硬編碼的值，請將它們設爲public final常量。

這種面向對象設計原則的好處在於維護。重要的是不要濫用它，複製不是爲了代碼，而是爲了功能。這意味着，若是您使用通用代碼來驗證 OrderID 和 SSN，並不意味着它們是相同的，不然未來將保持不變。

經過將通用代碼用於兩種不一樣的功能或事物，您將它們永久地緊密結合在一塊兒，而且當 OrderId 更改其格式時，SSN 驗證代碼將中斷。

所以請小心這種耦合，不要將任何使用類似代碼但無關的東西組合在一塊兒。

2.封裝變化

在軟件領域中只有一件事是不變的，即 「更改」。所以，封裝您指望或懷疑未來會更改的代碼。這種 OOP 設計原則的好處在於，它易於測試和維護正確的封裝代碼。

若是您使用 Java 進行編碼，則遵循如下原則：默認狀況下將變量和方法設爲private，並逐步增長訪問權限，例如，從private到protected而不是public。

Java 中的幾種設計模式都使用 Encapsulation，Factory設計模式是 Encapsulation 的一個示例，它封裝了對象建立代碼，並提供了之後引入新產品而不影響現有代碼的靈活性。

3.開放式封閉設計原則

類，方法或函數應對擴展開放（新功能），併爲修改關閉。這是另外一種美麗的 SOLID 設計原則，它能夠防止他人更改已經嘗試和測試過的代碼。

理想狀況下，若是僅添加新功能，則不該測試您的代碼，這就是開放式封閉設計原則的目標。順便說一下，該原則在 SOLID 首字母縮寫詞上表明 「O」。

4.單一責任原則（SRP）

單一責任原則是另外一種 SOLID 設計原則，在 SOLID 首字母縮寫詞上表明 「S」。根據 SRP，更改類不該有一個以上的緣由，不然一個類應始終處理單個功能。

若是您在 Java 的一個類中放置了多個功能，則它會引入兩個功能之間的耦合，即便您更改了一個功能，也有可能破壞了耦合功能，這須要進行另外一輪測試，以避免對生產環境形成任何意外。

5.依賴注入或反轉原理

儘可能不要依賴，它將由框架提供給您。這已在Spring 框架中很好地實現，此設計原理的優勢在於DI 框架注入的任何類都易於使用模擬對象進行測試，而且易於維護，由於建立對象代碼放在框架比放在客戶端代碼中要好不少。

有多種方法能夠實現依賴項注入，例如使用某些 AOP（面向方面​​的編程）框架（如 AspectJ）所作的字節碼檢測，或像 Spring 中那樣使用代理來實現。

6.偏心組合而不是繼承

若是可能的話，我主張使用組合而不是繼承。大家中的某些人可能會爭論這一點，但我發現 Composition 比 Inheritance靈活得多。

組合容許經過在運行時設置屬性並使用接口來構成一個類，從而在運行時更改類的行爲，所以咱們使用了多態性，該多態性能夠隨時隨地替換更好的實現。

即便是《Effective Java》書籍也建議使用組合而不是繼承。

7.Liskov替代原則（LSP）

根據 Liskov 替換原則，子類型必須能夠替換爲父類型，即便用父類類型的方法或函數必須可以與子類的對象一塊兒工做而沒有任何問題。」

LSP 與單職責原則和接口隔離原則密切相關。若是一個類具備比子類更多的功能，則可能不支持某些功能而且確實違反了 LSP。

爲了遵循 LSP SOLID 設計原則，派生類或子類必須加強功能，但不能減小功能。LSP 在 SOLID 首字母縮寫詞上表明 「L」。

8.接口隔離原理（ISP）

隔離接口原理規定，若是客戶端不使用接口，則不該實現該接口。大多數狀況是在一個接口包含多個功能且客戶端僅須要一個功能而沒有其餘功能時發生的。

關聯設計是一項棘手的工做，由於一旦發佈接口，您就必須在不破壞全部實現的狀況下進行進行更改。

這種設計原則在Java中的另外一個好處是，該接口的缺點是在任何類均可以使用它以前先實現全部方法，所以意味着儘量實現具備單一功能的方法。

9.使用接口而不是實現

始終使用接口而不是使用實現編程，這將致使靈活的代碼能夠與任何新的接口實現一塊兒使用。

所以，在Java中對變量，方法的返回類型或方法的參數類型使用接口類型。

在許多Java書籍中都建議這樣作，包括在《Effective Java》和《Head First設計模式》書籍中。

10.受權原則

不要本身作全部事情，而是將其委託給相應的類。委託設計原理的經典示例是Java的中的equals()方法和hashCode()方法方法。爲了比較兩個對象是否相等，咱們要求類自己進行比較，而不是由Client類進行比較。

此委託原則是該原理的另外一個示例，其中將事件委託給處理程序進行處理。

總結

全部這些 面向對象的設計原則 都經過提升高內聚性和低交換性來幫助您編寫靈活、更好的代碼。這是理論的第一步，可是最重要的是 開發發現什麼時候應用這些設計原理的能力。

一旦掌握了這一點，接下來就是學習Java中的設計模式，該模式將使用這些設計模式來解決應用程序開發和軟件工程中的常見問題。

找出咱們是否違反了任何設計原則並損害了代碼的靈活性，可是因爲這個世界上沒有什麼是完美的，因此不要老是嘗試用設計模式和設計原理來解決問題，它們主要用於大型企業項目，由於更長的維護週期。

不管如何，這是全部這些OOP設計原則的不錯的總結。

興趣拓展

若是您真的對Java編碼技巧與實踐更感興趣，請閱讀Joshua Bloch撰寫的《Effective Java 中文 第三版》 ，這是編寫Java Collection API的人的寶藏。在公衆號【Java知己】，後臺回覆：Effective Java，能夠得到該書籍。

這本書充分利用了各類面向對象和SOLID設計原則，對編寫更好的代碼有很大幫助。

他們向咱們展現瞭如何在編碼和Java程序中使用設計原理。Java開發工具包遵循許多設計原則，例如BorderFactory類中的Factory Pattern，Runtime類中的 Singleton模式，各類java.io類上的Decorator模式。

歸根結底，專業程序員應該始終努力實現高度凝聚力和鬆散耦合的解決方案，代碼或設計。從Apache和Google尋找開源代碼是學習Java和OOP設計原理的一些好方法。

---

「不積跬步，無以致千里」，但願將來的你能：有夢爲馬 隨處可棲！加油，少年！

關注公衆號:「Java 知己」，天天更新Java知識哦，期待你的到來！

• 發送「Group」，與 10 萬程序員一塊兒進步。
• 發送「面試」，領取BATJ面試資料、面試視頻攻略。
• 發送「玩轉算法」，領取《玩轉算法》系列視頻教程。
• 千萬不要發送「1024」...