Java中的繼承與組合
繼承是面向對象最顯著的一個特性。繼承是從已有的類中派生出新的類,新的類能吸收已有類的數據屬性和行為,並能擴展新的能力。那麼Java中的繼承與組合是怎樣的呢?以下僅供參考!
當Java 1.5引入註解,企業開發者對簡化EJB和其他企業產品開發抱有很大期望。可以看一看同一時期的一篇文章用EJB 3.0簡化企業Java開發。
然而從那時起,Java企業使用註解出現一些無法預料的後果和副作用,一些甚至到今天都沒有被注意到。幸運的是,並非所有的副作用都沒有被注意到,來看一些例子,在StackOverflow標題為“Why Java Annotations?”有很多有價值的評論,“Are Annotations Bad?”這篇文章有很棒的觀點,還有“Magics Is Evil”,“Annotations…Good, Bad or Worse?”。
java-programmer
並非所有的註解都相同
儘管上面許多討論都包含有價值的觀點,但並不是所有註解都是相同的。
這裏有兩類註解,區別在於他們是否在運行期影響程序。首先,説一下無害的一類,它們並不會在運行期對代碼產生任何影響;另一種是有害的一類,它們會修改運行期行為。無害的註解包括@Deprecated, @Override, @SuppressWarnings, 等等。有害的註解包括@Entity, @Table, @PostConstruct, @ApplicationScoped,等等。
在無害的註解中存在一小部分註解,它們非常實用。有一些提供在編譯期間(靜態檢查)捕獲錯誤或提供安全保障。一些實用的註解包括:@Override, @NonNull/@Nullable 來自(Checker Framework), 等等。
為什麼有害的註解不好?
我們定義了一些有害的註解,為什麼要避免使用它們呢?
想象一個標準的Java Data類擁有@PostConstruct方法。這個註解表示所標註的方法應該在對象創建好之後被調用。這個功能並不是由JVM處理,所以Date類隱式獲取未知的框架和容器,而自身語義上並沒有做任何事情。如果這些代碼並不運行在任何容器中,而只是運行在JVM中呢?這個註解大大降低了這個類的重用性。另外對於任何使用Date的地方進行單元測試就變成了噩夢,因為你必須確保每次都正確綁定post-construction,要模擬一個兼容的容器。這就有點可笑了,一個Date類需要一個容器來運行,但這確實是有害的註解對類、方法和參數的影響。
無可否認,業務邏輯往往復雜,需要更多依賴和關係,而不僅僅是一個簡單的Date類。然而沒有理由在一個類中顯式或隱式地添加不必要的依賴或約束,有害的註解就是:依賴和約束。
企業陷阱
不幸的是有害的聲明在Java Enterprise 5大規模合法化。為了更正早期企業API的易用性問題,註解用來隱藏系統中宂餘的和難用的部分。新的JEE 5被稱讚為”輕量級”和”簡單”,表面上看起來是這樣。但是一個微小的,同時也是至關重要的誤用蔓延開來。
@Statelesspublic class DocumentRepository { public Document getDocument(String title) {
...
}
...
}
如果想要獲取一個Stateless EJB,“只需要”在類上聲明@Stateless註解。確實,編寫這個類只需要只一點動作,但是請注意這個類中有害的註解綁定了幾百頁的説明文檔,而且只能在百萬字節的應用服務器(Application Server)上運行。這又怎麼能稱的上是”輕量級”呢。所以,這個註解僅僅是真正需要編寫的Java代碼的佔位符而已,代碼仍需要以某種形式存在。現在只不過是隱藏在註解之下。
不幸的是,這種變通方案稱為一種模式,現在有害的註解廣泛分佈:JPA, CDI, Common Annotations, JAXB 等等。
有害的`註解有時會出現在錯誤的地點
因為註解通常作為開發環境,有時有害的註解被當做單一職責原則(Single Responsibility Principle)或關注點分離(Separation of Concerns)的最佳實踐。
讓我們來考慮一下下面這個CDI例子:
@ApplicationScopedpublic class DocumentFormatter {
...
}
上面的註解描述這個類應該是一個CDI Bean,意味着它應該只能由CDI實例化,並確保每個應用中只有一個實例。
這些信息並不屬於這個類。這個服務在功能上(無論什麼方式)並不會對它在當前應用中的作用產生影響。這裏有兩個明顯的關注點。
一個JPA的簡單例子:
@Entity@Table("PERSON")public class Person {
...
}
問題在於這種類往往是”領域對象(domain objects)”,它們直接將領域模型持久化。更糟的是,數據傳送對象(DTO)用來在對象之間傳送數據,使得整個構造變得脆弱,因為對象間耦合過於緊密。不管怎樣,這是一種錯誤的方式。
所有的這些附加的功能和(或)信息應該從這些類中分離出來,但是它們卻悄悄混在一起,因為它們”只不過”是註解。
有害的註解有時蔓延
註解有時會傳染其他對象。回顧上面那個CDI Bean。每個使用它的對象,每個依賴它的對象現在都擁有一個CDI註解,否則依賴關係樹就不會構建成功。
@Entity註解也一樣。因為對象之間的關係,其他對象也通過註解持久化,很快所有的持久化對象都會有這個註解。我們無法使用原生的第三方對象(除非序列化或包裝它們),我們無法使用其他持久化機制(比如用NoSQL DB存放對象)。
這些註解使得這些對象無法複用。它們只能在一個嚴格的、受控制的、不透明的環境中使用,不能和任何東西整合。
有什麼替代品?
是XML嗎?當然不是,至少對於上面的例子來説不是。
Spring框架使用配置來管理對象,因此可以用XML當做配置文件。然而,是否某個依賴需要在運行期改變,而不通過重新編譯?如果不需要,那麼很難説配置應該用另一門語言來表示,尤其重構困難、測試困難、管理需要特殊工具。
真正的替代品當然是好的Java代碼,正確封裝並解耦的。是的,用代碼來管理對象,儘管有時被當做樣板(boilerplate),但並不算糟糕。它帶來一些好處,比如讓代碼可讀、可調試、可重構。只有那些長片的、複雜的、宂餘的樣板是糟糕的,比如“關於EJB 2.0”。但是解決方案並不是擺脱所有的樣板或用另一種語言隱藏樣板,而是簡單幹淨的架構,直接而不多餘的信息,簡單併合適的方式來面向對象。
這也適用於JPA、Spring和其他東西。誤用註解來表示功能會發生Stcakoverflow上這個問題“Arguments Against Annotations”,為什麼不用已有的工具呢:比如Java語言本身和編譯器,來解決這類問題,面向對象和軟件最佳實踐。
總結
如果註解在代碼運行期加上了額外功能和約束,那它是有害的。這很糟糕,因為它隱藏了類或方法的切面,使之難懂、難複用、難重構、難測試。
不幸的是Java Enterprise不理睬Java開發者社區中發對註解的聲音。所以企業級Java和其他”官方”框架更不可能重視這類問題。
至少我們可以持續關注有害的註解,如果可能儘量避免使用,編寫新的框架和軟件替換掉註解,不會出現有害註解所帶來的問題。
-
java虛方法
我們已經討論了方法的重載,也就是子類能夠重載父類的方法。以下是小編為大家搜索整理的java虛方法,歡迎大家閲讀!更多精彩內容請及時關注我們應屆畢業生考試網!當子類對象調用重載的方法時,調用的是子類的方法,而不是父類中被重載的.方法。要想調用父類中被重載的...
-
Java開發崗位面試題
為幫助參加Java開發崗位面試的朋友們做好準備,以下是本站小編搜索整理的一份Java集合面試問題40個【附答案】,供參考練習,希望對大家有所幫助!想了解更多相關信息請持續關注我們應屆畢業生考試網!一、Java基礎1、String類為什麼是final的。2、HashMap的源碼,實現原...
-
Java編程語言初學者入門課程
初學者先弄清這些Java的基本概念也是必不可少的,死記硬背肯定是不行的,重在理解,理解它們之間的區別與聯繫,分別有哪些應用。希望對您有所幫助!更多內容請關注應屆畢業生考試網!一、先明白瞭解什麼是Java的四個方面。初學者先弄清這些Java的基本概念也是必不可少的...
-
Java程序設計示例教程
本文以實例形式詳細講述了Java的反射機制,是Java程序設計中重要的技巧。分享給大家供大家參考。具體分析如下:首先,Reflection是Java程序開發語言的特徵之一,它允許運行中的Java程序對自身進行檢查,或者説"自審",並能直接操作程序的內部屬性。例如,使用它能獲得Java類...