Annotations真能使J2EE開發(fā)簡易化嗎？
應(yīng)it168寫的專稿.http://publish.itpub.net/j/2007-11-08/200711080938078.shtml
隨著J2EE進(jìn)入5.0時(shí)代后，Java EE5.0的很多特性也被廣泛應(yīng)用在J2EE程序中。而Java EE5.0的注釋（Annotations）特性就是其中應(yīng)用最廣泛的特性之一。
如果稍微瀏覽一下最新的Java EE5.0（EJB3.0，JPA）的標(biāo)準(zhǔn)規(guī)范，就可以發(fā)現(xiàn)，這些規(guī)范的制定者或是支持者們宣稱最多的莫過于，利用這些規(guī)范可使開發(fā)變得像開發(fā)POJOs一樣的簡單與簡潔。但是，如果對(duì)那些源代碼稍加瀏覽或查看，最引人注目的可能就是那些取代了XML描述作用的注釋。那么，筆者們禁不住要問一句，注釋的使用真的可以簡化復(fù)雜的J2EE或組件的開發(fā)嗎？
一、 引言
在以前的J2EE版本中，都是使用大量的配置文件來設(shè)置Web程序、EJB等。但這一切在Java EE5.0中得到了徹底的改善。Java EE5.0中的注釋(Annotation)是專門針對(duì)Web和EJB程序而設(shè)計(jì)的。如@Resource、 @EJB和@WebServiceRef等，以及其它一些與安全相關(guān)的注釋，如@RunAs和@DeclareRoles。
在Java EE5.0中，這種對(duì)元數(shù)據(jù)(Meta-data)的支持的數(shù)據(jù)就是注釋。通過使用注釋， 程序開發(fā)人員可以在不改變原有邏輯的情況下，在源文件嵌入一些補(bǔ)充的信息。代碼分析工具、開發(fā)工具和部署工具可以通過這些補(bǔ)充信息進(jìn)行驗(yàn)證或者進(jìn)行部署。舉個(gè)例子，例如希望某個(gè)方法的參數(shù)或者返回值不為空，雖然可以在Java doc中進(jìn)行說明，但是表達(dá)同樣意思的作法有很多，比如“The return value should not be null”或者“null is not allowed here”。測試工具很難根據(jù)這些語言來分析出程序員所期望的前提條件(Pre-condition)和執(zhí)行后的條件(Post-condition)。而使用注釋(Annotation)，這個(gè)問題就可以輕而易舉的解決。
注釋，簡單的說，就是代碼里的標(biāo)記，這些標(biāo)記可以在類加載、運(yùn)行時(shí)或是編譯的時(shí)候可以被解釋。這給人的感覺極像C++的macros。
其實(shí)說起注解語法，對(duì)于任何一個(gè)Java開發(fā)人員來說都已經(jīng)耳熟能詳了，我們每天都在使用著 的@author、 @param等等，其實(shí)都是在編寫注釋，然后用Javadoc生成文檔。Java的這種方便的文檔生成方法受到了開發(fā)者的普遍贊譽(yù)。而從JDK1.5開始，注釋語法提供了更為強(qiáng)大的功能。
二、 注釋——真的能簡化嗎？
筆者問過一些做Java開發(fā)的朋友關(guān)于對(duì)注釋的了解情況。很多都說，在實(shí)際的項(xiàng)目當(dāng)中，依然在使用Java1.4及EJB2.0，因?yàn)檫€沒有到不得不使用注釋的時(shí)候。當(dāng)然，在平時(shí)的學(xué)習(xí)當(dāng)中，可能會(huì)有涉及到注釋。
注釋是代碼文件中的偽代碼，而代碼之外的一些配置文件，如XML及*.properties，感覺更加容易從編譯過的部署類里具體化。這兩者可能各有優(yōu)點(diǎn)，那我們普通的開發(fā)人員依據(jù)什么來決定，到底是把元數(shù)據(jù)寫在源文件代碼里，還是寫在單獨(dú)的配置文件中呢？
有一點(diǎn)可以肯定，其它能像Java這樣提供注釋功能的語言并不多。引入注釋的目的無非就是想把一些需要單獨(dú)或是額外解決的問題，引用于源文件中一并解決，但這并不一定能起到藥到病除的效果。
讓我們看看使用注釋在類文件中寫入配置信息的情況：這意味著需要重新編譯才能反映配置信息的改變，配置不能在Java程序外面單獨(dú)的加以操作與配置。同時(shí)，對(duì)于使用那些支持注釋及非注釋兩種類型的框架，無疑會(huì)使項(xiàng)目的配置更加混亂，增加維護(hù)難度。
如果一個(gè)軟件在試運(yùn)行或是真正使用時(shí)，碰到用戶需求變化或者原來功能不能正常運(yùn)行，如果一些基本的配置信息都寫進(jìn)Java源文件中，一般的作法是：需求反饋到該程序設(shè)計(jì)程序員，程序員修改代碼，再進(jìn)行測試，可能測試不通過，影響其他功能了，再測試，折騰很長時(shí)間，最后編譯打包，交付客戶。
如果使用XML和Java分離方式：水平較低的維修人員趕到現(xiàn)場，修改一下配置XML，無須編譯Java代碼，測試，馬上解決問題。很明顯哪個(gè)更快呢?
所以，開發(fā)軟件不能只顧自己開發(fā)時(shí)方便，還要考慮到運(yùn)行維護(hù)時(shí)是否方便，軟件不像冰箱，制作好交給用戶，很堅(jiān)固，很穩(wěn)定，用戶也不會(huì)提出什么修改意見，當(dāng)然海爾的定制化冰箱有這個(gè)意思，但是這種水平不是一般廠商水平能夠做出來的。
當(dāng)然，筆者并不反對(duì)或是拒絕任何可以提高軟件開發(fā)效率及節(jié)約時(shí)間的方法或技術(shù)，但這有個(gè)前提，就是這種技術(shù)或方法的成本或是代價(jià)。有些人會(huì)說，將一些部署邏輯或是信息嵌入在代碼中，這樣可以減少文件的間接訪問，增加代碼的集中度。但是，在一個(gè)滿是注釋的源文件中，去提取特定的配置注釋，這無疑會(huì)增加代碼的分析時(shí)間。此外，筆者們又如何給那些沒有源文件的類文件進(jìn)行注釋呢？最后，注釋又為何要整一套自己的新語法？它本來就像Java語法，那有必要另起爐灶，再整一套自己的語法嗎？
當(dāng)然，筆者也承認(rèn)，注釋有它肯定的一面，并且可以肯定，其初衷是好的。但筆者認(rèn)為，在EJB3.0規(guī)范中，其注釋的規(guī)范有些太過極端了。因?yàn)楹苊黠@，這已經(jīng)違背了軟件的簡易性原則，增加了開發(fā)的復(fù)雜性，使代碼的可維護(hù)性降低了。
三、 注釋——使J2EE開發(fā)變得容易一些
我們知道，注釋其實(shí)也是一種修飾符，在可以使用其它修飾符（比如public，static，或 final）的任何地方都可以使用注釋。按規(guī)定，注釋優(yōu)先于其它修飾符。它包括一個(gè)@符號(hào)，@后接注釋類型和被括號(hào)括起來的元素值對(duì)。這些值必須是編譯時(shí)常量。也就是說 Java本身就提高了注釋信息的詳細(xì)列表。注釋并不直接影響程序的語義，但它影響工具和庫處理程序的方式，從而對(duì)運(yùn)行程序的語義產(chǎn)生影響。注釋可從源文件、class文件中閱讀，也會(huì)在運(yùn)行時(shí)得到反映。將定義從執(zhí)行中分離出來并提供一種可以內(nèi)省約束的方式，這使得執(zhí)行過程更加靈活。大多數(shù)Java開發(fā)者已經(jīng)很熟悉注釋了，比如所有的JavaDoc標(biāo)簽和瞬時(shí)標(biāo)簽都是注釋的例子。
普遍的觀點(diǎn)都認(rèn)為，配置信息最好不要使用注釋寫在源文件中，因?yàn)檫@樣需要每次編譯修改過注釋的類，最好是將其寫成單獨(dú)的XML等文件。
任何J2EE 開發(fā)者都知道開發(fā)Java 程序其實(shí)并不簡單。但新的Java EE 5.0將使你的開發(fā)過程變得容易一些。Java EE 5.0具有Web 服務(wù)支持、注釋和增強(qiáng)的CMP性能。
要開發(fā)一個(gè)簡單的J2EE應(yīng)用程序，程序員必須要寫大量的樣本文件代碼（如JavaBeans企業(yè)版）和設(shè)定無數(shù)個(gè)配置文件（XML中的描述文件）。所以要成為一個(gè)J2EE開發(fā)者，程序員必須熟悉EJB和XML。對(duì)于初學(xué)者來說，這些將令他們望而生畏。
目前的J2EE說明書（1.4）非常長，是用較老的JDK 1.2版本寫的，這使J2EE更加復(fù)雜難懂。新的JDK版本提供了豐富的、簡單好用的性能，比如Java EE 5.0的一般性能和注釋支持。
而最新的Java EE 5.0，其中一個(gè)主要目的就是，既保持J2EE強(qiáng)大的功能，又可以使一般的開發(fā)任務(wù)變得容易一些。為了達(dá)到這個(gè)目的，Java EE 5.0將提供更好的默認(rèn)性態(tài)和設(shè)置，允許大多數(shù)容器無需使用部署描述符就可以得到需要的東西。為此，Java EE 5.0做了很多注釋。開發(fā)者不需要知道執(zhí)行的細(xì)節(jié)（由容器完成執(zhí)行任務(wù)）。這些新性能都使企業(yè)的Java應(yīng)用程序更小、更快。
四、 注釋——有所為，有所不為
注釋作為元數(shù)據(jù)的保存或是持有是很實(shí)用的。例如，在構(gòu)建一個(gè)實(shí)體類或是控制器時(shí)變得很方便。同時(shí)，在兩個(gè)不同類之間進(jìn)行關(guān)聯(lián)時(shí)也很有用。
但是，如果把注釋作為配置目的來使用，則有違它最初的設(shè)計(jì)初衷。因?yàn)榕渲梦募蛐畔⑹墙?jīng)常需要修改的，例如數(shù)據(jù)庫的映射文件等，在這方面使用注釋，顯然有濫用或過分使用的成分。因此，在這方面，Java EE5.0及Hibernae走得有點(diǎn)偏了，這常常使得注釋在元數(shù)據(jù)與配置文件之間混用。
但是，這并不能說注釋是有問題的，只能說是使用者誤用問題造成的。注釋比較適合用于元數(shù)據(jù)的定義或保存。但并不適用于應(yīng)用運(yùn)行的配置信息。
此外，注釋另外一個(gè)很成功的應(yīng)用可能就是在JUnit4 API里的應(yīng)用。如：
增加一個(gè)@Test注釋，而不需要像以前那樣寫成testXxx()；
增加一個(gè)@Test注釋，就可以替代以前的try/catch出錯(cuò)處理了；
增加一個(gè)@Before@After注釋，可以替換以前的setUp()等方法；
增加一個(gè)@RunWith(Parameterized.class)及一個(gè)方法@Parameters public static Collection<Object[]> parameters()，被測試類的構(gòu)造參數(shù)都保存在Object[]里。這樣就進(jìn)行參數(shù)化的測試了，而無須像從前那樣public static Test suite()。
據(jù)筆者所知，JUnit框架中注釋的使用，的確使它變成更加的靈活，代碼更加的緊湊。
其實(shí)，注釋只是我們普通開發(fā)人員手里的一個(gè)工具，它也許是一個(gè)新玩意，帶有幾分的新鮮，但也有幾分的討厭，其實(shí)也是一把雙刃劍。筆者記得當(dāng)初學(xué)習(xí)設(shè)計(jì)模式的時(shí)候，就想把所有的這些模式趕快應(yīng)用到開發(fā)當(dāng)中，不管適用不適用。只有當(dāng)這種新鮮感過后，才能正常與正確的使用這些新特性。
五、 小結(jié)
那注釋到底用還是不用呢？筆者認(rèn)為，把注釋應(yīng)用到有意義的地方，而不是一味的濫用即可。例如，在那些沒有注釋就不能運(yùn)行的地方肯定需要就注釋。再如，改變注釋將可能導(dǎo)致運(yùn)行時(shí)類的行為，那可以考慮使用注釋。
Java EE5.0使用注釋這樣新語法，替代XML，當(dāng)然，修改元注釋還是需要重新編譯的，這和修改源碼沒有兩樣，但是如果沒有單元測試這一人工工程管理跟上，程序上線正式運(yùn)行，因?yàn)榇中牡雀鞣N瑣碎問題全部爆發(fā)，更是可怕。
另外，筆者認(rèn)為，ROR中的約定優(yōu)于配置（Convention Over Configuration ），這種做法Java的框架可以借鑒一下，在前期把問題都解決，這總比到了維護(hù)實(shí)施后期左找右改XML要強(qiáng)吧，犧牲了靈活性得到的卻是可靠和穩(wěn)定。使用ROR這樣的解釋語言，對(duì)于注釋的修改是不需要編譯，當(dāng)然約定優(yōu)于配置不是ROR首先提出來，默認(rèn)簡單，容易上手，需要細(xì)節(jié)還是可以使用XML配置。總之，約定優(yōu)于配置是基于XML基礎(chǔ)上的改進(jìn)。當(dāng)然，筆者不反對(duì)探索簡化，但是目前探索結(jié)果還是發(fā)現(xiàn)，XML比較穩(wěn)定，符合分離OO思想，能夠健壯地對(duì)付擴(kuò)展和維護(hù)。