簡介
盡管您可能認為編寫需要分析文本的 java 應用程序是一項簡單任務，但象許多事情一樣，它會很快變得復雜起來。那的確是我在編寫代碼以解析 Html 頁面時的經驗。開始的時候，我偶然會使用 Perl5 正則表達式（regeXP）。但是，由于某些原因（稍后說明），我后來經常使用它們。

背景知識
在我的經驗中，大多數 Java 開發人員都需要解析某種文本。通常，這意味著他們最初要花一些時間使用象 indexOf 或 substring 那樣的與 Java 字符串相關的函數或方法，并且希望輸入格式永遠不變。但是，假如輸入格式改變，那么用于讀取新格式的代碼維護起來就會變得更復雜、更困難。最后，代碼可能需要支持自動換行（Word wrapping）、區分大小寫等。

由于邏輯變得更加復雜，所以維護也變得很困難。因為任何更改都可能產生副作用并使文本解析器的其它部分停止工作，所以開發人員需要時間修正這些小錯誤。

有一定 Perl 經驗的開發人員可能也有過使用正則表達式的經驗。假如夠幸運（或優秀）的話，這位開發人員能夠說服團隊其余的人（或至少是團隊領導）使用這項技術。新的方法將取消編寫用來調用 String 方法的多行代碼，它意味著將解析器邏輯的核心委托出去，并替換為 regexp 庫。

接受了有 Perl5 經驗的開發人員的建議后，團隊必須選擇哪個 regex 實現最適合他們的項目。然后他們需要學習如何使用它。

在簡要地研究了從因特網上找到的眾多可選方案后，假設團隊決定從人們更熟悉的庫中選擇一個使用，如屬于 Jakarta 項目的 Oro。接下來，對解析器進行較大程度地重構或幾乎重新編寫，并且解析器最終使用了 Oro 的類，如 Perl5Compiler、Perl5Matcher 等。

這一決定的后果很明顯：

• 代碼與 Jakarta Oro 的類緊密地耦合在一起。
  
  
• 團隊承擔了風險，因為不知道非功能性需求（如性能或線程模型）是否將得到滿足。
  
  
• 團隊已花費時間和財力來學習并重新編寫代碼，以使它使用 regexp 庫。假如他們的決定是錯誤的并且選擇了新的庫，則這一工作在成本上將不會有很大區別，因為將需要再次重新編寫代碼。
  
  
• 即使庫工作正常，假如他們決定應該遷移到全新的庫（例如，包括在 JDK 1.4 中的庫），怎么辦？

去耦的好處
有沒有辦法使團隊知道哪個實現最適合他們的需要呢（不僅現在能將來也能）？讓我們試著尋找答案。

避免依靠任何特定的實現
前面的情形在軟件工程中十分常見。在有些情況中，這樣的情形會導致較大的投資和較長的延期。當不了解所有后果就作出決定而且決策制定人不太走運或缺乏必需的經驗時，就經常會發生這種情況。

可將該情形概括如下：

• 您需要某種提供者
  
• 您沒有選擇最佳提供者的客觀標準
  
• 您希望能用最低的成本來評估所有的待選項
  
• 所作的決定不應將您束縛在所選的提供者上

這一問題的解決方法是使代碼更加獨立于提供者。這引入了新的層 ― 同時去除客戶機和提供者的耦合的層。

在服務器端開發中，很輕易找到使用該方法的模式或體系結構。下面引用一些示例：

• 對于 J2EE，您主要關注如何構建應用程序而不是應用程序服務器的細節。
  
• 數據訪問對象（Data access Object，DAO）模式隱藏了如何訪問數據庫（或 LDAP 服務器、xml 文件等）的細節和復雜性，因為它提供了訪問抽象持久存儲層的方法，而您則不需要在客戶機代碼中處理數據庫問題（數據實際存儲在哪里）。這不是四人組（Gang of Four，GoF）模式，而是 Sun 的 J2EE 最佳實踐的一部分。

在假想的開發團隊示例中，他們正在尋找這樣的層：

• 抽象所有正則表達式實現背后的概念。團隊就可以著重學習和理解這些概念。他們所學的可以應用到任何實現或版本。
  
  
• 支持新的庫且沒有副作用。基于插件體系結構，動態選擇執行 regexp 模式的實際庫，并且適配器不會被耦合。新庫僅會引入對新適配器的需要。
  
  
• 提供比較不同可選方案的方法。一個簡單的基準實用程序就可以顯示有趣的性能測量結果。假如對每個實現都執行這樣的實用程序，團隊就會獲得有價值的信息并能選擇最好的可選方案。