世界上最短又最長的距離－抽象層

「在過去的這10年之中，IT界大體上沒有什麼太大的變化。」

大多數朋友聽到以上這句話，或許會深深不以為然。「誰說變化不大？每天推出一些新技術、新名詞，把我們技術人員搞的昏頭轉向，東西學也學不完! 心中已經萌生放棄一切，改賣鹹酥雞的念頭了！」。如果你一樣無法同意筆者的論點，那麼底下我想試著說服您。

萬變不離其宗

把自己過去所學拿出來，靜心地想一想，這些所謂的新技術、新名詞，真的是讓人耳目一新的東西嗎? 有人說Web Services是新東西，其實只是過去的RPC （Remote Procedure Call）技術，如CORBA、COM、RMI等的變種，基本原理根本沒改變，幾乎僅是將原來二進位的資料傳輸方式，改用XML罷了。 有人說JDO、EJB、Hibernate是新技術，其實這些不過是基於O/R Mapping概念的實現與改進。有人說Struts、JSF（JavaServer Faces）是新技術，然而這些Framework的設計，卻沒有偏離過MVC Design Pattern的概念，也從來沒有脫離過HTML的大門。

還有最近幾年最困惑各公司CIO以及CTO的問題：「該選用Java Solution或.NET Solution？」、資訊相關科系學生最常問的問題：「該學Java或.NET？」，殊不知，Java跟.NET本質上幾乎是一樣的東西，縱然應用上互有消長，卻沒有人會因為學了另外一個東西，導致難以融入另外一種技術，君不見國內某位Java界大師級人物，並非一開始就進入.NET領域，可是他對.NET技術的領悟，卻高於其他早已進入的技術人員。

更有趣的是，原本設計給Java的開放原始碼工具，也都跑出了.NET版，如Ant變成NAnt、JUnit變成NUint、Hibernate變成NHibernate。表面上水火不容的技術，私底下卻不斷地發生「和親」事件，眼光銳利的開發人員，一眼就看破假象，不會被官方的行銷語言唬的一愣一愣的。

那麼，到底什麼東西改變了？

那麼，為什麼會出現那麼多的新名詞困擾IT從業人員呢? 答案很簡單——因為抽象層越來越多。這些年來，改變的並不是技術的本質，而是為了讓開發工作更簡單，更有效率、更容易維護，所以不斷出現各式各樣的抽象層。

什麼叫做抽象層呢？簡單的來說，只要你所撰寫的程式碼，需要經過轉換才能執行，那麼這個轉換的工具就稱為抽象層。舉例來說，現在網頁上最火熱的Flash，裡面所使用的ActionScript，最後經過Flash的Runtime Engine解譯才能執行，所以Flash Runtime Engine就是一種抽象層。有人嫌Flash還是太難，所以發展了Flex、或是開放原始碼的Open Laszlo，開發人員撰寫的是XML，可是最後卻轉換成Flash呈現在網頁上，所以Flex和Open Laszlo就是一種抽象層。 抽象層的實例俯拾即是。

組合語言太難寫，那就發明更高階的C語言。C語言的指標太難搞，就搞個沒有指標概念的Java。Java還是太難，再用Java寫個Script語言，例如BeanShell。一層包一層，即使最後執行的指令還是與組合語言指令相距不遠的機器語言，但是開發人員至少與機器相隔了三重天。

CGI太難寫，所以發展了Servlet。Servlet還是太複雜，沒關係，有JavaServer Pages。開發人員覺得JavaServer Pages還是太難，那設計一堆可以重複使用的Tag Library總行了吧。可是開發人員更希望像開發VB程式一樣，拖拖拉拉就可以寫出程式，只好再發展JavaServer Faces滿足開發人員的胃口。

誰知道接下來還會以這些為基礎，發展出什麼新玩意兒呢？開發人員所開發的動態網頁，哇～隨便講講又和最基本的HTML隔了四重天、五重天。於是，開發人員和機器隔離的越來越遠，真實地成為了世界上最短又最長的距離。而太多的層次，最大的缺點就是效能，不斷地轉譯，耗費更多的記憶體，也讓 2GHz的處理器，執行應用程式的速度，好像沒有比過去DOS時代的486快多少。就好像一個國家，如果政府機構一層又一層，行政效率肯定不高，而且還會浪費公帑。

抽象層帶來了什麼好處？

雖然說抽象層會造成效率的下降，系統資源的耗損，可是卻帶來了一個很大的優點－彈性。彈性可以展現在很多面向上，對Java開發人員來說，展示彈性最基本的地方莫過於Java本身的Reflection機制，乍看之下，Reflection和C++所具備的RTTI（Runtime Type Information）類似，不過Reflection機制卻可以帶來更有威力的應用。

一般而言，實作系統程式（Application Server、Container、IDE等）的工程師比較有機會用到Reflection，一般的開發人員很少有機會體驗Reflection所帶來的好處。甚至因為誤用，以為做出了一個非常有「彈性」的系統，結果卻是一個太過「鬆散」，難以維護的系統。

知道Reflection能夠怎麼用，以及如何正確地使用，就是一個重要的課題。Manning出版社所出版的《Java Reflection in Action》正是一本這樣的書籍。薄薄的273頁，道盡所有和Reflection有關的議題，很多深入的知識讓其他書籍難以望其項背。

本書一開始就介紹Method Object，以及Method Object所帶來的動態呼叫（Dynamic Invocation）功能，讓開發人員可以在程式執行時期，先查詢類別所具備的Method，然後再決定叫用哪一個Method。充分讓讀者享受到Reflection的強大威力。 接下來，作者為大家介紹Field Object，這是一個可以在執行時期得知物件所具有的欄位之功能。此功能的重要性在於，Java的序列化永續儲存功能（Serialization），或是我們在整合開發工具之中所看到的Property Sheets，都是原自Field Object所具有的功能。從這裡開始，讀者開始接觸系統程式（System Programming）的實作。

作者在本書中，花了兩個章節，解釋類別載入器（Class Loader）以及動態載入的功能，可以讓讀者更了解Reflection功能的來龍去脈。在本書中，最重要的，莫過於講述Java Dynamic Proxy的章節，這大概是眾多Java相關書集中，將Dynamic Proxy解釋的最清楚的一本書。

正常的Java程式設計師，會接觸到Dynamic Proxy的少之又少，可是，它卻又在我們的生活中扮演重要的角色，舉凡EJB技術與JAX-RPC技術中常常用到的Stub/Proxy，或是單元測試工具JUnit，都有Dynamic Proxy的存在，如果您想知道這些技術如何運作，那麼這一章是絕對不能省略的。

在本書最後兩個章節，作者利用一個章節說明Reflection所帶來的缺點－效能降低，該如何去量測與面對，讓開發人員不至於『言必稱Reflection』，結果造成一個沒有效率的系統。而最後一個章節，作者說明了J2SE 5.0之後，JSR 14 Generic以及JSR 201 Language Extension在Reflection所帶來的對應改變，更談到了各種具有Reflection特性的Java競爭者（最大的當然是C#），讓大家了解其他語言在Reflection機制上與Java的差異性。作為一本介紹Java Reflection的書籍，本書可以說是「鞠躬盡瘁」。

更多的抽象層，最後世界會變得如何呢？

雖然抽象層帶來了一個千變萬化的世界。不過筆者開始對無窮無盡的抽象層感到厭煩。當這些抽象層越來越多，會不會有一天，引發下一波的革命，反璞歸真呢？

這是一個有趣的議題，筆者也期待著下一波革命的到來。

《作者簡介》
王森，現任昇陽教育訓練中心經理，及Run!PC、iThome專欄作者，曾著《深入淺出KJava》、《Java手機程式設計入門》、《Java深度歷險》、《手機/PDA程式設計入門》等書，並於Run!PC開闢Java與PDA、Java與手機、深入JDK、Web Services的應用等專欄 。