愛德華日誌

這主題向來是討論區上常被提出的問題，一言以蔽之，選擇最好的或最受歡迎的…

選擇最受歡迎的，站在你自己的角度來看，它可以提高你在市場上的身價，讓你找的到工作，可以填飽肚子。而站在別人的角度來講，你開發出來的系統容易讓別人接手，開發系統時可用的支援較多，市場的接受度較高，不用重新教育使用者。

選 擇最好的，一方面是可以接觸新思維，提供不同的視野。另一方面，則是期望有一天，最好的可以變成最受歡迎的。而早期投入者，多少可以收到 "傳教士" 般的尊崇待遇。還記得以前 XML 剛出來時，大力推廣 XML 的勞虎，在網路上廣泛傳送其免費電子書《無廢話 XML》，而今多少學習 XML 的網民，還是感念其恩德啊!

那麼，以下便是我的選擇。我會說明其主要應用，及個人對它的觀感。

最受歡迎：

C/C ++：這應該是正統資訊工程科系都必修的語言吧，它的應用不但能讓你直指核心(C)，也能讓你站在物件的具像高度(C++)，思考系統的構成。像是系統程 式、原生應用程式、軔體、Driver 等，皆是 C/C++ 應用所及之處。尤其台灣電子產業相對發達，在各種掌上型、智慧型裝置不斷推陳出新的今天，對C/C++的人力資源有高度需求。不過這個語言(尤其 C++)因為承載太多歷史包袱，各種實作變體太大，開發時常需用很多 tricks，在應用時需要付出較多心力，在程式語言本身及各種環境歧異的細節上!

Java：如果你唸資工 系，但學校 C/C++ 課程非必修，那麼至少 Java 是必修課程吧! Java 除了較少用在系統程式外，其他領域幾乎都占有一席之地。由於 Java 具有良好的物件導向基礎，當代許多企業應用皆採 Java Solution，尤其是在 SOA/ESB/EAI 等領域。採用 Java Solution 的好處是自由度高，但缺點就是很多事情沒有標準作法，或支援標準作法的解決方案太多，往往要花費不少時間在選擇如何架構系統上。

C# & VB.NET：這能讓你賺錢! 可以讓你快速的寫出漂漂亮亮的應用程式! 能讓你與微軟的企業系統做 完美的結合。像是 BI(OLAP、Reporting、Data Mining)那一塊，是 Java 在應用上比較需要費心的。而 .NET 相對於 Java 較緊緻的技術堆疊，能讓開發者較專注於應用程式的開發上。缺點是，離開了微軟平台的世界，就幾無用武之地。

PHP/Ruby：如果你想 run 自己的 business，或想建立一個像黑米、放P、挖女孩那樣的網站，相信我，這是一個很好的選擇。不過由於目前這兩個語言主要用途只在 Web 開發上，因此特別要注意典範的轉移，或是其原來專精的部分不再具有優勢。

就 典範轉移：我的意思是，PHP/Ruby 除了在 Web 開發上已有成功的 killer apps 之外，其實它們能做的事，其他語言或平台也都能做，除非它們能在別的應用領域一樣成功，否則對其未來發展仍是一項危機。而就 "其原來專精的部分不再具有優勢"，這並非不可能發生，請見以下的 ECMAScript 說明。但好消息是，至少在 2007 年，這兩個語言的排名在 TIOBE 上的排名都是往上升的。

最好的：

Python： 真正的跨平台，除了跨 Windows, Linux 這類原生作業平台外，它也有 Java 及 .NET 虛擬機器的移植版本。在 Java 與 .NET 競相誇炫平台能力之際，Python 仍能堅守語言本身的原味之美，是令人讚賞的。也因如此，Python 的應用領域眾多，從 Web、文字及檔案處理、科學到研究等，幾乎無所不包。事實上，很多研究平台內定的 scripting language 就是 python，像是用於統計的 SPSS、用於資料探勘的 Clementine 等。

D：被視為是 "C++ done right!" 的一個程式語言，支援了許多 C++/Java/C# 共有的特徵(OOP)，但卻也有些特徵是其他語言所欠缺(或尚在研議中)像 Out function parameters,Nested functions,Function literals,Closures,Resizeable arrays...。在現今 VM 當道的年代，D 仍編譯為 native executable，可見其定位，是比較接近 C/C++ 的。也就是適合拿來撰寫系統程式、原生應用程式、伺服器程式，以及網路應用程式等。不過，對於 D 被廣泛接受仍有重大疑慮，因直至目前為止還不知有任何較大型的專案採用 D 語言開發。相較於 Ruby 也沒有像 RoR 那樣的殺手級應用出現。

最受歡迎+最好的：

ECMAScript/JavaScript/ActionScript：JavaScript 與 ActionScript 都朝 ECMAScript 標準靠攏。本來 JavaScript 是被某些人唾棄的一無是處，以為它只會在瀏覽器上作作表面功夫的語言，但一朝 Ajax 的應用得到普遍的喜愛，JavaScript 的行情也就跟著水漲船高。但如果只是這樣，對於 ECMAScipt 最新標準的推廣倒不見得有多大助益。特別是後來 ActionScript 也遵循 ECMAScript 標準，而且號稱 ActionScript 3.0 是非常遵循，這就好玩了。因為 ActionScript 是應用在 Flex/Flash player 中，而瀏覽器中主要執行的指令語言是 JavaScript， 而這兩者都是當代 Thin Client/RIA 的主流，因此我們可以說 ECMAScript Family 幾乎已成為 Universal Client Lauguage。

再 者，認為 JavaScript 只會在瀏覽器上作作表面功夫其實並非事實。早期 Netscape Enterprise Server 及 BroadVision One-to-One Server，在 JSP 尚未出現前，伺服器上執行的指令語言就是 JavaScript。而前文提到現在是 VM 當道的年代，現在 ActionScript 的 engine 也已成為一個 VM，叫 AVM，且已貢獻給 Mozilla，成立 Tamarin 專案，將來若用於 Firefox 中，網頁內的 JavaScript 跑起來說不定會跟飛的一樣。

若是真有人拿 AVM 來寫伺服器，說不定會光復 JavaScript 在 Server 端的失土哦 (好吧! 天方夜譚)! 說真的，AVM Server 版若成(例如成為 Apache 的一個 module)，要威脅 Java 或 .NET 既有地位是比較困難，因為這兩個平台既有應用多、進化動力也強；但對其他 Server 端的 Scripting Language 絕對是個威脅。想想看，若你能在 Server 端及 Client 端同時使用 ECMAScript，那使用 Ruby 或 PHP 的誘因是否會漸漸變弱呢！而 Ruby 會紅，並不是語言本身之美所致，而是出了一個 Ruby on Rails Framework，而 framework 裡面的 concepts 是很容易 porting 到別的語言或平台中的。

其他：

看 了以上個人挑選出來的清單，看啊看的，現在還是程序導向和物件導向語言的天下。難道沒有其他不一樣思考面向的東西嗎? 有的，而且我們也還滿常用，像是 SQL，或是各式 Markup Language 了(雖然不是程式語言)。還有那些用在工程、模擬、統計分析、人工智慧上的，你沒有那個環境或從事相關職業，是幾乎無從著手的語言，而這些當然就不算在推 薦之內。

結語：

一項語言要被廣為接 受，在過去，我一直以為大廠的支援是個必要因素，但 PHP(XOOPs, Nuke...) 及 Ruby(RoR) 這種透過 Community 及 Killer Application 來帶動風潮的成功案例，似乎也印證了 "世界是平的" 的論點，在這個網路世代，不只大企業，小企業及個人一樣有機會。Killer Apps 與 Success Stories，可能比大廠背書更有價值。

而 對於你的選擇，我想，如果要做個尋常的程式開發人員，我會建議你 ECMAScript Family 一定要學，那 Java 或 .NET 再選一種。若你是個不尋常 (開發特殊應用的軟體) 的程式設計師，通常也就沒什麼好選了，因為應用的型式就決定了我們的選擇。

2006/05/03 使用 Eclipse Web Standard Tools 開發 Web Service

一直想要找一個方法，可以讓我直接將 JavaBean 轉換成 Web Service，而不需要太大的 coding effort。之前試過 SpringFramework 對 Web Service 的支援，基本上它也是要你自己去編一大堆的組態檔，好像也沒輕鬆到哪去。而 JAX-RPC 2.0 則是借用 JDK 5.0 對 Annotation 的支援，用起來跟 .NET web service 的寫法很像。但我仍在思考，是否存一種更乾淨的作法，可以不用 Annotation…

今天心想我已經為 Eclipse 裝上 Web Standard Tools，何不就試試它的 web service 開發能力呢。一試之下驚為天人，怎麼可以這麼好用。基本上它為 server 端的 web service 的開發提供兩種支援：

1. 給定一個 Java 類別，它可以為你產生合適的 WSDL 檔
2. 給定一個 WSDL 端點，它為你產生 Java 樣版
   

然後包含 web.xml、server-config.wsdd 的產生或修改、它都幫你做到好。其實它還有許多好用的功能，像是直接在 WSDL 上新增方法，甚至 refactor WSDL 等，絕對值得一試。

Eclipse WST 的WSDL 圖形編輯器

想了解更多 Eclipse WST 如何開發 web service，可參考：Developing Web Services Eclipse Web Tools Project

Web Service 測試小技巧

寫起來免得自己忘記。如果你有個 web service 叫 HelloMath，其中有個 method 為 add(int a, int b)，你可以不用寫程式，直接瀏覽 http://some.url.to/services/HelloMath?method=add&a=1&b=2 進行測試。

這個方法在以 Axis 為服務套件的 web service 上行得通。.NET 預設也有類似用法。至於其他的 web service 套件，就請自行測試了。

----***----

2004/02/10 Java Web Service 簡介

談到對於 Web Service 的支援，多數專家會認定 .NET 平台比 Java 好。個人認為就易用性而言，這可能是真的(只是可能)；不過若就支援的標準來說，Java 肯定是贏家。

這個領域的重要成員包括：

• 來自 Sun 的 Java Web Services Developer Pack (Java WSDP)，含括以下幾個套件:
  
  • JavaServer Pages Standard Tag Library (JSTL)
    
  • Java WSDP Registry Server
    
  • Web Application Deployment Tool
    
  • Ant
    
  • Tomcat
    
• 另外一個要角則是來自 Apache 的 Axis(Apache eXtensible Interaction System，據說是 IBM donate 的)。Axis 有許多特異功能。例如只要把一般的 Java Class 的副檔名由 .java 改為 .jws，就可以立刻變身為 web service，可作為獨立的 web server 等
  

其他專案

The Simple Messaging Framework: "The Simple Messaging Framework provides an elegant way to create robust and flexible Web services. It is based on the document-style Web services paradigm that uses the full power of XML Schema. This approach enables you to expose arbitrarily complex business objects and services with ease."

2006/05/03 使用 Eclipse Web Standard Tools 開發 Web Service

一直想要找一個方法，可以讓我直接將 JavaBean 轉換成 Web Service，而不需要太大的 coding effort。之前試過 SpringFramework 對 Web Service 的支援，基本上它也是要你自己去編一大堆的組態檔，好像也沒輕鬆到哪去。而 JAX-RPC 2.0 則是借用 JDK 5.0 對 Annotation 的支援，用起來跟 .NET web service 的寫法很像。但我仍在思考，是否存一種更乾淨的作法，可以不用 Annotation…

今天心想我已經為 Eclipse 裝上 Web Standard Tools，何不就試試它的 web service 開發能力呢。一試之下驚為天人，怎麼可以這麼好用。基本上它為 server 端的 web service 的開發提供兩種支援：

1. 給定一個 Java 類別，它可以為你產生合適的 WSDL 檔
2. 給定一個 WSDL 端點，它為你產生 Java 樣版
   

然後包含 web.xml、server-config.wsdd 的產生或修改、它都幫你做到好。其實它還有許多好用的功能，像是直接在 WSDL 上新增方法，甚至 refactor WSDL 等，絕對值得一試。

Eclipse WST 的WSDL 圖形編輯器

想了解更多 Eclipse WST 如何開發 web service，可參考：Developing Web Services Eclipse Web Tools Project

Web Service 測試小技巧

寫起來免得自己忘記。如果你有個 web service 叫 HelloMath，其中有個 method 為 add(int a, int b)，你可以不用寫程式，直接瀏覽 http://some.url.to/services/HelloMath?method=add&a=1&b=2 進行測試。

這個方法在以 Axis 為服務套件的 web service 上行得通。.NET 預設也有類似用法。至於其他的 web service 套件，就請自行測試了。

----***----

2004/02/10 Java Web Service 簡介

談到對於 Web Service 的支援，多數專家會認定 .NET 平台比 Java 好。個人認為就易用性而言，這可能是真的(只是可能)；不過若就支援的標準來說，Java 肯定是贏家。

這個領域的重要成員包括：

• 來自 Sun 的 Java Web Services Developer Pack (Java WSDP)，含括以下幾個套件:
  
  • JavaServer Pages Standard Tag Library (JSTL)
    
  • Java WSDP Registry Server
    
  • Web Application Deployment Tool
    
  • Ant
    
  • Tomcat
    
• 另外一個要角則是來自 Apache 的 Axis(Apache eXtensible Interaction System，據說是 IBM donate 的)。Axis 有許多特異功能。例如只要把一般的 Java Class 的副檔名由 .java 改為 .jws，就可以立刻變身為 web service，可作為獨立的 web server 等
  

其他專案

The Simple Messaging Framework: "The Simple Messaging Framework provides an elegant way to create robust and flexible Web services. It is based on the document-style Web services paradigm that uses the full power of XML Schema. This approach enables you to expose arbitrarily complex business objects and services with ease."

Links:

• JDBC in C++: a commercial product which provides the functionality to use JDBC in C++. Have a look(none open-source).
• Loki C++ Library: Loki is a C++ library which demonstrates and encourages the use of generic programming and designe patterns. It was written to accompany the book entitled 'Modern C Design.' The library includes a parametrized smart pointer class, generalized functors, a multithreading abstraction, and some help for important patterns.
• OpenTop: Cross-Platform C++: OpenTop is a radically new C class library that provides the means to create powerful and robust network-oriented applications and greatly simplifies their development.

  At its core, OpenTop contains framework classes that provide vital facilities that are absent from the C standard library. These include:

  • Networking
  • Unicode
  • Multi-threading
  • Memory and resource management
• The Boost C Libraries: C++ libraries for boost your performances.
• Log for C++: Log4cpp is library of C classes for flexible logging to files, syslog, IDSA and other destinations. It is modeled after the Log4j Java library, staying as close to their API as is reasonable.
• ACE Overview: The ADAPTIVE Communication Environment (ACE) is a freely available, open-source object-oriented (OO) framework that implements many core patterns for concurrent communication software. ACE provides a rich set of reusable C wrapper facades and framework components that perform common communication software tasks across a range of OS platforms. The communication software tasks provided by ACE include event demultiplexing and event handler dispatching, signal handling, service initialization, interprocess communication, shared memory management, message routing, dynamic (re)configuration of distributed services, concurrent execution and synchronization.
• Crypto Library 5.1 - a Free C Class Library of Cryptographic Schemes: Crypto Library is a free C class library of cryptographic schemes.
• nn-utility: THE AIM OF THE NN-UTILITY project is to create a neural network library that takes care of the tedious programming of networks in object oriented C . The library makes the creation of network topologies and weight definitions very easy. The library also has some default functions, making the programming of sigmoid, kohen, binomial, and radial basis functions simple. On top of this the library is composed of some accessories, like simple bitmap creators and readers, enabling networks to be trained with bitmaps.
• IT++: A C++ library of mathematical, signal processing, speech processing, and communications classes and functions. It has been developed by researchers in these areas. The kernel of the package are templated vector and matrix classes and lots of functions for vectors and matrices. As such the kernel is similar to the Matlab functions.

自從 del.icio.us 書籤服務面世之後，以 tag 做為資訊分類的方式便受到普遍的歡迎。

tag 資訊分類具有許多優點，像是你可以自由的，動態的為選定的資訊指定分類；系統可以透過 tag 與資訊項目間的關係，為你的資訊建立 tag cloud，或透過 tag 找尋相關的資訊…

然而 tag 的使用情境亦有其限制。通常我們在使用 tag 分類資訊時，會先有所要記載的資訊，然後再針對此資訊指定其 tag。例如在使用 del.icio.us 時，你會先找到要儲存的書籤連結，然後再指定 tag 給這一連結。但資訊儲存與搜集的使用情境並不總是如此。

有些時候，我們已經知道了一些資訊體系，而想對此一體系中的各個主題作深入的探察。在這種情況下，使用 tag 來標示此資訊體系便不適合了。

舉個例子吧! 假設我所感興趣的知識體系如下：

• 社會科學
• • 心理學
  • • 認知心理學
    • 組織心理學
    • 行為科學
  • 管理學
  • • 企業管理
    • 專案管理
  • 經濟學
  • • 個體經濟
    • 總體經濟

我想要根據這個知識體系去作深入的研究。由於我手上還沒有可供記載的資訊來源，在現有工具的限制下，我無法透過 tag 的方式，事先組織一個這樣的知識架構。

這個時候，傳統的 directory/category 分類模式就派上用場了。你可以在還沒有資料項目的情況下，就先建好一個研究的知識體系。目前支持目錄分類的 online bookmark manager 中，比較著名的是 spurl 及 netvouz。

spurl 及 netvouz 都同時支援了 tag 及 category 的分類方式。它們的 category 模式，也都支援多層及多子類別的分類。美中不足的是，它們都沒有為 tag 及 category 這兩種分類方式，找到一個無縫整合的方法。

基本上，tag 分類可視為是一個扁平化的 category。基於此一前提，一個可能的無縫整合方式，即是讓 tag 可以直接組織成樹狀結構，我稱之為 TagTree。TagTree 與目前netvouz 及 spurl 所採用的方式不同，因為後兩者所採用的模式，是讓你在儲存一個資訊項目時，分別指定它是屬於哪些 tags，以及哪一個類別。category 及 tag 分類，分別屬於兩個不同的命名空間 (namespace)。

TagTree 讓 tag 可以直接組織成類別目錄，則讓 tag 與 category 同屬於一個命名空間。這樣做有何好處呢？

1. 你可以在還沒有資訊項目的情況下，就以分類目錄組織你的知識體系
2. 當你為資訊項目指定分類時，仍以 tag 方式為之，而不同顧及 category 的組織
3. 當你查詢資料項目時，可以依照 directory tree 的方式，以知識體系的順序瀏覽，也可以透過 tag index 的方式，直接定位到相關的概念
4. 如 果讓一個 tag 可以包含多個子 tag，而同一 tag 又可同時屬於不同的 parents，就很容易的達到讓同一資訊項目，歸屬不同的分類目錄的功能。舉例而言，假如你所儲存的資訊項目，是有關如何用 java 程式來處理 xml 格式之資料，在許多分類目錄系統中，你無法讓它同時歸到 xml 或 java 這兩個分類(除非用複製的方式)。但假若採用這裡所提的方式，我們可以指定 java 屬於 programming，而 xml 屬於 informationscience，則當我們為資訊項目標上 xml 與 java 這兩個 tags 時，TagTree 自然會將它歸到 programming/java, information science/xml 這兩個分類目錄之下。
   

注意到，這裡的重點是，這個方法在 tag 資訊項目時，完全不用付出組織分類目錄的負擔。而組織 tag tree 的時機，可以發生在資訊項目搜集之前或之後；也就是說，你可以隨時調整你的 tag tree。另外，為了使用的便利性，TagTree 並不強調所有 tags 都應納入樹狀階層的體系。

除了用來分類書籤之外，TagTree 當然也可以用分類想法、文件或部落文章。進行質性研究的人士，可能發現 TagTree 可以有助於紮根理論中的編碼程序。

Having fooled around with drupal and wordpress for several months, I got some thoughts on generic CMS. Here goes the list:

• Simplified URL: Don't encode any date or context informations in the page URL. Use id number(the drupal way) or slug(the wordpress way) instead. Encode information such as publishing date in URL will cause broken link in other page if the original page changes its publishing date.
  
• Free tagging: Tag pages with keywords so that we can quickly find it again and know relationships between pages. For example, the "see also" function is just a listing for those pages have the same tags with the current one.
  
• Tag tree: Content authors manually group tags into tree. It helps to build knowledge ontologies without having contents.
  
• Tag cloud: System automatically group tags into cloud. Can be use as index.
  
• Free linking: Wiki like pages linking. Beside free linking, no more wiki markup. Instead, use
  
• Rich text editing.
  
• SVG on-line drawing: the superior of SVG graph format is encoded with XML. We can edit a SVG drawing once and once again just like we do in handling HTML. On-line SVG drawing let us no more authoring a drawing in client and then upload it to the server. All we need is a web browser.
• Flex type: Add new page types without programming.
• Faceted: Categorizes pages with multi-dimensional attributes. Think of a bug report is just a general page with the faceted of critical level, bug type, resolution status, etc.
  
• Book: Organize pages into hierarchical books. A page can belong to several books. The order of pages is specified by the book which contains it.
• Search folder: Searches can be save as folders. It helps to create different type of topic listing such as forum, blog, issue tracking system, and so on.
  
• Comment page: comment is a general page.
  
• Paging for every list.
• RSS for every list.
• Should integrate with portal system.
  

這是我在之前的 blog 中所提到的觀點。有幸 Jini 也在他的 blog 中提出回應，讓我有機會，將這樣的想法作更進一步釐清。

首先讓我聲明一點，在我的前文中，以「EJB 3.0 叫好不叫座」作為標題的一部分是不適當的，因為該段的內容所評論的，主要是針對物件導向方法與軟體架構設計而發。把 EJB 3.0 放在一起討論，將不相關的議題混在一起，模糊了敘述的主軸。

所以，在這篇 blog 中，我將針對物件導向方法與軟體系統設計上的一些心得，加以陳述。

* 典範轉移，物件導向不再獨領風騷

近兩三年來的確有許多軟體設計上的新思維，取得了前所未有的注目，諸如 Aspect-Oriented Programming(AOP)、Service-Oriented Architecture(SOA)、Meta Programming(以 Java 來講是 Attribute/Annotation-Oriented Programming、Declarative Programming，甚至簡單講就是 reflection)。當然這些程式設計典範(paradigm) 在推出時，都會強調並不是用來取代物件導向設計，而是與物件導向相輔相成。

讓我這樣說吧! 以上所出現的這些新的設計典範，沒有一個是在設計小程式時需要用著的。你會發現不管是 AOP, SOA, MP 甚至是簡單的 reflection，都是在設計大系統、設計 framework 才會用著的東西。例如，EJB 3 中大量採用 Annotation 來簡化部署描述，為什麼？以物件導向的觀念來說，一個系統最好全部採用物件導向的機制來實作，這樣才有「概念的整體性」性嘛。Annotation 算是物件導向技術嗎？我不認為。那為什麼還要犯了「概念整體性」、「思想純淨性」的忌諱採用這種方式呢？

原因是很簡單的，當我們(至少是我)開發大系統或 framework 時，我需要元件(想像成 EJB) 與平台(想像成 JavaEE 容器) 間，或各個元件彼此之間有更容易的溝通與互動方式，也就是我前文所講的：

當你往上堆砌系統，或一開始即採用架構導向系統開發方法(Architecture Oriented System Development)時，比較適當的思維模式，是將系統看作一部"機器"，你考慮的應當是系統各部元件之間的連結，彼此間如何互動，最後才是各部元件 各自的角色與職責。

以純淨的物件導向技術來實作的話，容器或框架會定義出一些(有時是很多)介面，讓符合其規格的元件實作。當然這就算是一種 IoC(Inversion of Control)，一種 callback。而這也是 EJB 2 大量採用的方式。但為什麼 EJB 3 要採用 Annotation 呢？這證明什麼，至少在某方面，Annotation 的思維可能較之物件導向思維，更適於解決某些系統間的溝通、互動角色。

* SOA 與物件導向思維之關係

SOA 的確如 Jini 所說，是透過支援一致的呼叫介面，讓異質系統可以互相串連的(當然用在同質系統中也行啦!)。然而我認為服務導向(或訊息導向) 與物件導向精神還有一個很大的不同點：服務導向架構更傾向使用 coarse-grain 的 API。相對的，物件導向方法為了充分表達領域物件的語意，通常會設計出 fine-grain 的 API。coarse-grain API 跟 fine-grain API 有什麼差別呢？

我以 EJB 中最符合 SOA coarse-grain API 型式的 JMS 來說明。我們撰寫 MessageDrivenBean 時，通常只需撰寫 MessageListener 的 onMessage(Message inMessage) 方法，然後在這個方法中，呼叫其他的物件(有可能是以 fine-grain style 寫成)，就可以製造出一個能夠自由組裝資訊流程的系統。試想，如果我們這裡不用 coarse-grain API，而用 fine-grain API 來作為訊息傳遞介面會如何？我的經驗是，fine-grain API 大大的阻絕了物件/類別的重用性。這一點只要想想，用 SessionBean 是否可以像 MessageDrivenBean 那樣擁有組裝的靈活性就可明白。所以這裡的重點是，fine-grain API 適合用來表達領域物件，而 coarse-grain API 適合用來作為整個系統的通訊介面。

* Annotation、Reflection 與物件導向觀念可能潛藏的衝突

這裡我說的是 "潛藏"，也就是在不良設計的情況下，並不是每個用到 Annotation、Reflection 技術的程式都會與物件導向觀念產生衝突。我從物件導向的三個特性說起。物件導向的特性是「封裝」、「繼承」與「多型」。接著我們再來想想 Annotation 的運作方式，它是在原始程式碼中定義一些 -- 好吧，就是 annotations，然後呢，在 compile time 或 rum time 時針對這些 annotations 做些處理。

當我們自己寫程式去處理 annotation 時，事實上是敲開一個類別，東看看、西看看 -- 偷窺別人的內在總是自在又痛快的事情，如果能夠痛下 鹹豬手自由 "存取" 一番，那更是淋漓盡致啦 -- annotation + reflection 給你這項偷偷摸摸的特權。而 (該死的) AOP, byte code generator 更讓你能打開類別的外衣，在裡面亂搞一通。

最明顯的，這裡嚴重的侵犯了類別的隱私(封裝性)。透過 reflection，你可以把類別的祖宗八代都叫出來。然後呢，有些本來該是用多型手法解決的問題，卻透過 annotation 或 AOP 之類的技法去解決。就算你的 annotation 或 AOP 設計精良，很可能程式的可追蹤性已變差；若是設計不良，就會產生比用 switch 敘述來取代多型的 bad smell 更難聞的 terrible smell. 所以這裡重點是，Annotation 不但與物件導向無關，甚且有害於物件導向。為採用 Annotation 的系統框架所寫的元件，極可能比採用 Dependence Injection 進入系統中的 POJO 元件更不易在別處重用。

* 同樣是 AOP，也有符不符合物件導向精神的區別

AOP 有好幾種實作方式，一種是直接在 java 語言中，增加支援 AOP 的語法，然後在編譯期將 AOP 的語法 waving 到 class byte code 中，這是 AspectJ 採用的方式。另一種是在架構上，以物件導向的方式(例如 proxy/interceptor pattern)，實作對 AOP 的支援，這是 Spring AOP 所用的方式。通常前一種方式對 AOP 特性的支援較為完整，例如可以在 statement 中對被剖析的程式動手腳(加入 advice)；後者則較差，像 Spring AOP 最細的 pointcut 就只到 method 層級。

照理說既然第一種方式對 AOP 的支援較為徹底，那我們應該多多採用 AspectJ 囉？事實上，我個人卻較傾向 Spring AOP。原因是，在 Spring AOP 中，可以用物件導向方式解決的，都盡量採用物件導向方式解決了。在 Spring AOP 中，不管是 pointcut 或是 advice 都是在實作特定的介面，因此這些類別，就算離開 Spring AOP 的環境，也還有重用的機會(只要你高興，你可以在一般的物件中呼叫)。而 AspectJ 的作法是增加 java 的語法，加入 aspect 元素(就像 class 元素一樣)，在其中定義 pointcut。然而 aspect 與 class 的關係是單向的，不用說這些 aspect 不能離開 AspectJ 的編譯器下運作，就算是一般的類別，都不能呼叫這些 advice(對，懂得人會問為什麼要這麼做？我的理由是，給我自由。)

這裡的重點是，對於解決一個問題，你可能有好幾種作法。這幾種作法中，有些作法可與現有系統完美的搭配，而有些作法卻是充滿阻抗，與系統格格不入。選擇很明顯，給我 AOP，但請盡量用物件導向的方式。

* 有時候就是用不到物件導向的思維

或說的仔細一點，不要物件導向過了頭。例如，你在開發報表程式，你希望這樣的程式可以在資料庫欄位異動時，仍可在畫面上正常顯示。這時候，你絕不會想要對 報表所在的表格進行領域塑模。因為這時候你該注意的，不是表格代表的領域觀點，反而是所有資料庫中共有的架構特性，你該塑模的，是想辦法將資料庫綱要，與報表的樣版合協互動的方法。沒錯，報表程式中的資料庫綱要在 Java 中的確也是用 class 來表示，你會比較看重它的連結(介面)觀點。

其他的程式，像是 OLAP 程式，或是可以自由組裝欄位內容、資訊分類的 CMS 系統，我也是寧願採用較為簡單的 ER 觀點。直接處理表格裡面的欄位資料，會比較具有靈活性。這有點類似於 coarse-grain API 的作法。

* Java 失去物件導向的純淨性，卻換來開發應用系統更大的自由

Java 1.0 與現今的 Tiger 相較，哪個 Java 版本較接近純淨的物件導向語言呢？無疑的大家會同意是 Java 1.0。任何事物一開始出現，總是有美好的中心思想，但受到世俗濁流的影響，不可避免的要由純淨走向混亂。有些語言為了避免被人發現這個現象，乾脆直接招認。像是 C++ 說自己是 Multiparadigm Programming，Perl 的哲學是 There’s More Than One Way to Do It。那麼 Java 呢？

當物件導向取代結構化程序設計觀點時，我們也是花了好久習慣，但終究沒有引起太大的阻力。原因是物件導向的功能完完全全的含括了結構化設計的所有功能。今天的困難是，還沒有一種獨立、總括的思維，可以完全含括物件導向的思維。或許架構 + 元件算是吧! 但是為了解決架構與元件間連結、互動的問題，我們採用了種種沒有中心思想的作法。失去了純淨，增加了選擇。

結論

群雄並起，各領風騷。物件導向架構的語法元素，取代程序性語法元素，成為基本的建構單元。今天我們看待一個 class，就像往昔我們看待一個 procedure, function 那樣自然。

一開始的時候，程式是資料結構 + 演算法。後來呢，程式變成是一堆一堆物件的連結，但其實物件裡面也是資料結構 + 演算法。而今呢，注意一下你的企業系統：Data Warehouse + SOA。Data Warehouse 是比較大的資料結構，SOA 是比較大的演算法(流程 -- 活動的組合)。

看起來好像沒什麼不同，不過，以前你企業裡面的資訊系統是一座座孤島。而今呢？整個企業是一支可以合協運作的大程式。這就像是一堆單細胞生物，與一個人的區別。

從荼毒員工說起

有一天上班時，上級主管要我 "寫一套程式，把 XML 裡面的資料轉換成 Excel 檔格式，越快越好"。一直以來，我就是用 Java 寫 AP，想一想這樣的東西用 Java 寫，好像還要花不少時間。因為我不知道他的 xml 檔案格式長怎樣，因此若要程式夠靈活，就必須要能讓使用者選擇所要匯出的節點。哦，這時 XPath 就派上用途了… 但事情還是沒那麼簡單，因為我不可能叫 end user 輸入 XPath。如此一來，只好把 XML 的樹狀結構顯示出來，讓使用者可以由樹狀結構中選擇要匯出的節點。想到這裡，我不禁為他的 "越快越好" 黯然神傷。

好吧，這時候我拿出 "當主管最大的特權"… 就是可以把事情交待給別人做。這個月部門值星官是 June 小妹，我把六月找來：「Boss 要一套程式，可以把輸入的 XML 匯出成 Excel 檔，越快越好，最好就是今天!」

XMLFox Advance 登場

六月面有難色，不過她還是不負所望，不多久，她就在 Google 的協助下，找到一套程式(當然不是自己寫的囉。主管其實重點不是要我們自己寫，而是要把 XML 匯出成 Excel 檔) 叫 XMLFox Advance 的 shareware。

嘿，這套共享軟體還真的好用，只要打開一個 XML 檔案，當瀏覽到連續同一型態性的元素時，就可以採用工作表的方式來展開。接著按右鍵，選擇 Export to，就可以將該序列元素的內容以表格的形式匯出了。

註：所謂序列 (sequence) 元素，是指形式如下的元素：

[sequence]
[item y="1" x="1" id="p1"/]
[item y="1" x="0" id="p2"/]
[item y="0" x="0" id="p3"/]
[item y="0" x="1" id="p4"/]
[/sequence]

也就是有元素名稱相同的重複子元素，且不同子元素屬性名稱最好也一致的節點。

事後除了感謝六月的快手，能在短短的時間內在網路上找到這套好用的軟體之外，我也想到，既然 XML 轉 Excel 格式檔是這麼普遍的功能，那麼 Excel 本身是不是就該內建這個功能呢？於是我打開 Excel 2003，試圖印證我的想法。(以下的 Excel 皆代表我所使用的 Excel 2003)

Excel 不負所望

略加測試之後，發現 Excel 果然如我預期，的確具備 XML 檔匯入的功能。只是若想得到一個漂亮的序列元素表，需要有些技巧。我的步驟是這樣的：

1. 從 Excel 開啟檔案對話窗中選擇一個有序列元素的 XML 檔中，Excel 會提示你下列對話窗，你要選擇「使用 [XML 來源] 工作窗格」。

Excel 接著會提示你以下訊息，按「確定」就是了!

2. 接下來 Excel 會在 XML 來源窗格中顯示 XML 的樹狀結構。注意其中 "資料夾" 圖示表示元素，而 "摺角文件" 圖示表示屬性。序列元素的資料夾圖示上，會有一個向下的按鈕，如下圖的 UM_Bin 元素：

3. 接下來用滑鼠拉曳你要展開成表格的序列元素，將它放至適當的你要展開的儲存格上。如下圖我是將 UM_Bin 元素放在 A1 儲存格上：

4. 再來，開啟清單工具列，點選其中的「重新整理 XML 資料」：

5. Excel 提示你資料匯入完成。按「確定」後可看見匯入的資料：

嗯! 整個過程就是如此。雖然不怎麼直覺，但也不會太難就是了。

Excel 載入 HTML 表格的功能

既然都可以匯入 XML 了，那麼載入 HTML 中的表格應也不成問題吧! 稍作測試，果然 Excel 也有這樣的功能。以下是我的操作步驟。

1. 在功能表上選擇「資料 / 匯入外部資料 / 新增 Web 查詢」。
2. Excel 彈出「新增 Web 查詢」視窗。在「地址」欄位中輸入資料來源的 URL：

3. 畫面上的箭頭指示你可選取的資料，點選你所要萃取的表格，讓它變成打勾狀：

4. 按「匯入」後，Excel 提示你要將資料放在哪裡，選一個你喜歡的儲存格就是了：

5. 最後，Excel 會將資料取回，置於你所指定的儲存格上：

結語

不得不承認，MS Ofiice 的設計還是挺符合人性。我在沒有看書，沒有參考說明檔的情況下，就能試出這樣的功能，便足以證明 MS Office 產品的可用性算是相當良好。有人懷疑，究竟 MS Office 所包含的功能裡面，一般的使用者究竟會用到幾分？其實我也的確這樣想，我可能不會用到它所有功能，但一旦我要的功能它有時，就會大大的減少我的負擔。

另外，我還要感謝那些被我荼毒的部門同仁，這可能是我農曆年前最後一篇 blog 了… 在此我要感謝你們帶著鋼盔向前衝的精神。有你們在，才能補足我思考的盲點，許多棘手的事情也變成可能。

在 Java Application Server 上使用 PHP

Caucho 在 Resin Application Serer 上加入對 PHP 的支援。其實在過去，Caucho Resin 就以其 JavaScript in JSP 的功能聞名。相關討論：

• TheServerSide: Caucho Resin adds PHP
• digg: 6 times faster PHP interpreter by Resin creators

我的第一個想法是，如果相容性做的好，那現有由 PHP 所實作的所有 CMS 在往後都可以很容易的 porting 到 servlet platform 上，也就不用擔心 JAVA 沒有好的 CMS 實作了。

Java 被 Scripting Language 取代?

還在擔心 Java 被 Scripting language 取代嗎? Java 其實是兩個層次上的東西，一個是 Java 語言本身，一個是與整個 JVM 有關的執行環境。目前可用於 JVM 上的平台的 Scripting 語言包括可以參考 "List of Java scripting languages"，另外，在 "Programming Languages for the Java Virtual Machine" 可以找到所有可以執行於 Java 平台的語言。

與此相關的 JSR 包括：

• JSR 223: Scripting for the JavaTM Platform
• JSR 241: The Groovy Programming Language
• JSR 274: The BeanShell Scripting Language

相信 jvm 在 sun 的努力下，終有一天會變成良好的 scripting 語言共通平台。

程式語言競技場

有人說 Java 比 C 還快? PHP 及 Python 熟強? 何不上「程式語言競技場」較量較是。你可以比較一下：

• C++ vs. Java -- 就效能上，當然是 C++ 強。但別忘了考慮平台、函式庫、跨系統整合上的支援，仍是 Java 的強項
• Python vs. PHP -- 還是 Python 強
• Java vs. Python -- Script 語言再怎麼強，在效能上還是沒搞頭
• D vs. C++ -- 效能上 D 語言小勝，不過由 Code Lines 可看出 D 語言更為簡潔
• D vs. Java -- "吃人夠夠"，Java 被 D 語言海扁。如果你的程式是要寫給自己玩的，可以拿 D 試試。

你用的語言過時了?

最後，大家要關心的，還是你所使用或學習的語言，是不是符合市場的趨勢，這裡有幾個連結，供大家參考：

• Programming Language Usage Graph
• Programming Language Popularity
• TIOBE Programming Community Index for January 2006