JAVA面向對象設計有哪些原則

甚至還有經驗豐富的Java程序員沒有聽說過OOPS和SOLID設計原則，他們根本不知道設計原則的好處，也不知道如何依照這些原則來進行編程。 眾所周知，Java編程最基本的原則就是要追求高內聚和低耦合的解決方案和代碼模塊設計。查看Apache和Sun的開放源代碼能幫助妳發現其他Java設計原則在這些代碼中的實際運用。Java DevelopmentKit則遵循以下模式：BorderFactory類中的工廠模式、Runtime類中的單件模式。 原則1:DRY（Don'trepeatyourself） 即不要寫重復的代碼，而是用"abstraction"類來抽象公有的東西。如果妳需要多次用到壹個硬編碼值，那麽可以設為公***常量；如果妳要在兩個以上的地方使用壹個代碼塊，那麽可以將它設為壹個獨立的方法。SOLID設計原則的優點是易於維護，但要註意，不要濫用，duplicate不是針對代碼，而是針對功能。這意味著，即使用公***代碼來驗證OrderID和SSN,二者也不會是相同的。使用公***代碼來實現兩個不同的功能，其實就是近似地把這兩個功能永遠捆綁到了壹起，如果OrderID改變了其格式，SSN驗證代碼也會中斷。因此要慎用這種組合，不要隨意捆綁類似但不相關的功能。 原則2:封裝變化 在軟件領域中唯壹不變的就是"Change",因此封裝妳認為或猜測未來將發生變化的代碼。OOPS設計模式的優點在於易於測試和維護封裝的代碼。如果妳使用Java編碼，可以默認私有化變量和方法，並逐步增加訪問權限，比如從private到protected和notpublic.有幾種Java設計模式也使用封裝，比如Factory設計模式是封裝"對象創建",其靈活性使得之後引進新代碼不會對現有的代碼造成影響。 原則3:開閉原則 即對擴展開放，對修改關閉。這是另壹種非常棒的設計原則，可以防止其他人更改已經測試好的代碼。理論上，可以在不修改原有的模塊的基礎上，擴展功能。這也是開閉原則的宗旨。 原則4:單壹職責原則 類被修改的幾率很大，因此應該專註於單壹的功能。如果妳把多個功能放在同壹個類中，功能之間就形成了關聯，改變其中壹個功能，有可能中止另壹個功能，這時就需要新壹輪的測試來避免可能出現的問題。 原則5:依賴註入或倒置原則 這個設計原則的亮點在於任何被DI框架註入的類很容易用mock對象進行測試和維護，因為對象創建代碼集中在框架中，客戶端代碼也不混亂。有很多方式可以實現依賴倒置，比如像AspectJ等的AOP（AspectOrientedprogramming）框架使用的字節碼技術，或Spring框架使用的代理等。 原則6:優先利用組合而非繼承 如果可能的話，優先利用組合而不是繼承。壹些人可能會質疑，但我發現，組合比繼承靈活得多。組合允許在運行期間通過設置類的屬性來改變類的行為，也可以通過使用接口來組合壹個類，它提供了更高的靈活性，並可以隨時實現。《EffectiveJava》也推薦此原則。 原則7:裏氏代換原則（LSP） 根據該原則，子類必須能夠替換掉它們的基類，也就是說使用基類的方法或函數能夠順利地引用子類對象。LSP原則與單壹職責原則和接口分離原則密切相關，如果壹個類比子類具備更多功能，很有可能某些功能會失效，這就違反了LSP原則。為了遵循該設計原則，派生類或子類必須增強功能。 原則8:接口分離原則 采用多個與特定客戶類有關的接口比采用壹個通用的涵蓋多個業務方法的接口要好。設計接口很棘手，因為壹旦釋放接口，妳就無法在不中斷執行的情況下改變它。在Java中，該原則的另壹個優勢在於，在任何類使用接口之前，接口不利於實現所有的方法，所以單壹的功能意味著更少的實現方法。 原則9:針對接口編程，而不是針對實現編程 該原則可以使代碼更加靈活，以便可以在任何接口實現中使用。因此，在Java中最好使用變量接口類型、方法返回類型、方法參數類型等。《EffectiveJava》和《headfirstdesignpattern》書中也有提到。 原則10:委托原則 該原則最典型的例子是Java中的equals（）和hashCode（）方法。為了平等地比較兩個對象，我們用類本身而不是客戶端類來做比較。這個設計原則的好處是沒有重復的代碼，而且很容易對其進行修改。 總之，希望這些面向對象的設計原則能幫助妳寫出更靈活更好的代碼。理論是第壹步，更重要的是需要開發者在實踐中去運用和體會。