程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> JAVA編程 >> 關於JAVA >> Java程序員應該了解的10個面向對象設計原則

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

編輯:關於JAVA

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

眾所周知,Java編程最基本的原則就是要追求高內聚和低耦合的解決方案和代碼模塊設計。查看apache和Sun的開放源代碼能幫助你發現其他Java設計原則在這些代碼中的實際運用。Java Development Kit則遵循以下模式:BorderFactory類中的工廠模式、Runtime類中的單件模式。你可以通過Joshua Bloch的《Effective Java》一書來了解更多信息。我個人偏向的另一種面向對象的設計模式是Kathy SIErra的Head First Design Pattern以及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() 方法。為了平等地比較兩個對象,我們用類本身而不是客戶端類來做比較。這個設計原則的好處是沒有重復的代碼,而且很容易對其進行修改。

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

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved