Java程序員應瞭解的10個面向對象設計原則

      面向對象設計原則是 OOPS（Object-Oriented Programming System，面向對象的程序設計系統）編程的核心，但大多數 Java 程序員追逐像 Singleton、Decorator、Observer 這樣的設計模式，而不重視面向對象的分析和設計。甚至還有經驗豐富的 Java 程序員沒有據說過 OOPS 和 SOLID設計原則，他們根本不知道設計原則的好處，也不知道如何依照這些原則來進行編程。

      衆所周知，Java 編程最基本的原則就是要追求高內聚和低耦合的解決方案和代碼模塊設計。查看 Apache 和 Sun 的開放源代碼能幫助你發現其餘 Java 設計原則在這些代碼中的實際運用。Java Development Kit 則遵循如下模式：BorderFactory 類中的工廠模式、Runtime 類中的單件模式。你能夠經過 Joshua Bloch 的《Effective Java》一書來了解更多信息。我我的偏向的另外一種面向對象的設計模式是 Kathy Sierra 的 《Head First設計模式》 以及 《Head First Object Oriented Analysis and Design》。

      雖然實際案例是學習設計原則或模式的最佳途徑，但經過本文的介紹，沒有接觸過這些原則或還在學習階段的 Java 程序員也可以瞭解這 10 個面向對象的設計原則。其實每條原則都須要大量的篇幅才能講清楚，但我會盡力作到言簡意賅。

      原則1：DRY（Don’t repeat yourself）

      即不要寫重複的代碼，而是用「abstraction」類來抽象公有的東西。若是你須要屢次用到一個硬編碼值，那麼能夠設爲公共常量；若是你要 在兩個以上的地方使用一個代碼塊，那麼能夠將它設爲一個獨立的方法。SOLID 設計原則的優勢是易於維護，但要注意，不要濫用，duplicate 不是針對代碼，而是針對功能。這意味着，即便用公共代碼來驗證 OrderID 和 SSN，兩者也不會是相同的。使用公共代碼來實現兩個不一樣的功能，其實就是近似地把這兩個功能永遠捆綁到了一塊兒，若是 OrderID 改變了其格式，SSN 驗證代碼也會中斷。所以要慎用這種組合，不要隨意捆綁相似但不相關的功能。

      原則2：封裝變化

      在軟件領域中惟一不變的就是「Change」，所以封裝你認爲或猜想將來將發生變化的代碼。OOPS 設計模式的優勢在於易於測試和維護封轉的代碼。若是你使用 Java 編碼，能夠默認私有化變量和方法，並逐步增長訪問權限，好比從 private 到 protected 和 not public。有幾種 Java 設計模式也使用封裝，好比 Factory 設計模式是封裝「對象建立」，其靈活性使得以後引進新代碼不會對現有的代碼形成影響。

       原則3：開閉原則

       即對擴展開放，對修改關閉。這是另外一種很是棒的設計原則，能夠防止其餘人更改已經測試好的代碼。理論上，能夠在不修改原有的模塊的基礎上，擴展功能。這也是開閉原則的宗旨。

      原則4：單一職責原則    

      類被修改的概率很大，所以應該專一於單一的功能。若是你把多個功能放在同一個類中，功能之間就造成了關聯，改變其中一個功能，有可能停止另外一個功能，這時就須要新一輪的測試來避免可能出現的問題。

      原則5：依賴注入或倒置原則

      這個設計原則的亮點在於任何被 DI 框架注入的類很容易用 mock 對象進行測試和維護，由於對象建立代碼集中在框架中，客戶端代碼也不混亂。有不少方式能夠實現依賴倒置，好比像 AspectJ 等的 AOP（Aspect Oriented programming）框架使用的字節碼技術，或 Spring 框架使用的代理等。

     原則6：優先利用組合而非繼承

      若是可能的話，優先利用組合而不是繼承。一些人可能會質疑，但我發現，組合比繼承靈活得多。組合容許在運行期間經過設置類的屬性來改變類的行爲，也能夠經過使用接口來組合一個類，它提供了更高的靈活性，並能夠隨時實現。《Effective Java》也推薦此原則。

     原則7：里氏代換原則（LSP）

      根據該原則，子類必須可以替換掉它們的基類，也就是說使用基類的方法或函數可以順利地引用子類對象。LSP 原則與單一職責原則和接口分離原則密切相關，若是一個類比子類具有更多功能，頗有可能某些功能會失效，這就違反了 LSP 原則。爲了遵循該設計原則，派生類或子類必須加強功能。

      原則8：接口分離原則

      採用多個與特定客戶類有關的接口比採用一個通用的涵蓋多個業務方法的接口要好。設計接口很棘手，由於一旦釋放接口，你就沒法在不中斷執行的狀況 下改變它。在 Java 中，該原則的另外一個優點在於，在任何類使用接口以前，接口不利於實現全部的方法，因此單一的功能意味着更少的實現方法。

     原則9：針對接口編程，而不是針對實現編程

     該原則可使代碼更加靈活，以即可以在任何接口實現中使用。所以，在 Java 中最好使用變量接口類型、方法返回類型、方法參數類型等。《Effective Java》 和《Head First Design Pattern》書中也有提到。

     原則 10：委託原則

      該原則最典型的例子是 Java 中的 equals () 和 hashCode () 方法。爲了平等地比較兩個對象，咱們用類自己而不是客戶端類來作比較。這個設計原則的好處是沒有重複的代碼，並且很容易對其進行修改。

總之，但願這些面向對象的設計原則能幫助你寫出更靈活更好的代碼。理論是第一步，更重要的是須要開發者在實踐中去運用和體會。

英文原文：10 Object Oriented Design principles Java programmer should know