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