對應於我們上一篇“ 診斷 Java 代碼”中所討論的透明盒可擴展性，黑盒可擴展性是指，在源代碼既不能查看也不能修改時，可以擴展軟件系統的方法。通常通過系統配置或使用特定於應用程序的腳本語言來進行這樣的擴展。在本專題中，Eric Allen 討論了何時設計黑盒可 擴展性的系統是有意義的，並提供了如何有效地實現這一設計的一些想法。閱讀了本文後，您將知道何時使用黑盒並掌握如何實現它的一些技巧。
我已在以前的文章中談到了代碼重用設計策略的重要性（主要是因為各種信息處理任務的差異和相應費用的增加），所以如果您已確定將系統可擴展性作為您的目標，那麼請先問一下自己“系統的可擴展性應該達到什麼程度，我能實現怎樣的可擴展？”然後，考慮下列方面：
對添加可擴展性的權衡，因為添加擴展性可能會降低性能或測試能力。
通常，測試性最好的系統就是最簡單的系統；添加可擴展性常常增加了復雜性。
規劃成功的可擴展設計的一個關鍵知識是，要知道您計劃以後如何擴展系統。
在本系列的 第一篇文章中，我曾概述了系統可以呈現的可擴展性的各種形式 ― 黑盒設計與兩種 白盒設計（ 透明盒與 開放盒）。 第二篇文章中，我詳細介紹了透明盒可擴展性的使用及實現，透明盒是一種恰當的介於黑盒與開放盒設計之間的設計方法。
這個月，我希望繼續我們的“旅行”，展開討論黑盒可擴展性。
在黑盒中探索方向
黑盒設計是一種可擴展性，它涉及到定制應用程序的用戶配置，使該應用程序以對特定環境最有用的方式執行。當用這種方法擴展應用程序時，就不必查看原始的源代碼了。
我們都使用過提供這種可擴展性的應用程序。例如，下面這兩個應用程序：
Netscape 的插件功能
在用 Emacs Lisp 配置方面，Emacs 具有無限能力
近期，幾乎每個新的應用程序都提供了某種程度的黑盒可擴展性。
如何識別一個配置腳本
在繼續之前，讓我嘗試區別配置腳本與程序的其它輸入之間的不同。不幸的是，這裡真的沒有什麼明顯的差別。程序接受的一組輸入（及程序解釋這些輸入的方法）都可以而且應該視作一種語言。但是您應該了解配置腳本的幾個顯著特征。
與其它程序輸入（每次使用應用程序時，都可以改變程序輸入）不同，配置腳本趨向於更為穩定。這些腳本一般有一些缺省值，這些缺省值最初將由用戶設置，並在很長一段時間內不會重置這些值。實際上，常在最初安裝程序時設置這樣的腳本。更改腳本的缺省值很可能會對程序在其它輸入上的行為有重大影響。而且，因為永久 存儲這些輸入的值，所以在隨後的程序調用中會檢索它們。
明智地選擇配置
現在，您可能詢問的下一個問題是“何時向應用程序添加這種可擴展性是有意義的呢？”
答案並非是添加盡可能多的可擴展性。畢竟，這種方法的最終結果是：給定適當的腳本（類似於 �berapplikation），單個應用程序就會執行用戶所需的每個任務。
可以論證，開發環境屬於這一類，但是用戶／開發人員所需的“腳本”可能會非常長且復雜。這個極端示例說明了對黑盒可擴展性的基本權衡 ― 應用程序提供的黑盒可擴展性越強，用戶針對特定環境而配置它所必須執行的工作就越多。
通常，最好對應用程序確定的要求范圍更窄一些，但仍可以通用，然後再針對更具體的環境。正如許多“極限編程（Extreme Programming）”小組所演示的那樣，縮小項目的范圍很可能還會使您真正地成功完成項目（而且還是准時的！）。
某些環境需要黑盒
不過，在某些環境中，您可以非常確定其中需要某一形式的黑盒可擴展性，而且您無需使用戶負擔過重就能提供這一可擴展性。在許多情況下，這仍需要先實現具有較窄范圍的應用程序的不可擴展版本，然後再在另一個版本中添加可擴展性。
您可能覺得這有點自相矛盾。畢竟，添加可擴展性的所有目的是減少實現系統中新功能的花費。如果知道要擴展應用程序，那為什麼不在開始時就構建可擴展性呢？因為構建不具備可擴展性的應用程序通常要便捷得多。
最初您能提供的應用程序版本越簡單，客戶就能越快地將它用於至少是他們的部分任務中。接著，您可以從 版本 1.0的銷售中獲得收益，來支持開發更具可擴展性的版本。
確定復雜性
考慮這一問題的關鍵是，您是否希望應用程序的可擴展版本在相當大的程度上要更為復雜。有時，設計應用程序的最簡單最自然的方法就是合並可擴展性。
這裡最好的示例之一是稅收計算應用程序。這樣的應用程序可以用於許多組稅單。使用哪組特定表單取決於特定的用戶；因此，使用特殊用途的配置語言來描述各種表單是很自然的。如果不是這樣，而將這些稅單硬連接到程序中（即，通過表單的類層次結構，其中每個表單有一個單獨的 類），並不會減少復雜性。
但是，一旦用黑盒可擴展性這一方法設計了應用程序，則不必修改，甚至不用查看源代碼，就能夠方便地添加新的表單（當下一財政年度必須這樣做時）。
還有其它一些應用程序示例，它們的黑盒可擴展設計是最簡單的。可以想到的示例有：Web 浏覽器，電視調度查看器（類似數字電視服務使用的查看器）和依賴於公理數據庫的自動化定理證明器。
值得自豪的語言
現在，假設您已決定為應用程序的某些方面提供一種配置語言。在決定這樣做時，需要確認的最重要一點是：要知道您是真的在設計一種語言。必須考慮與編程語言設計者有關的相同類型的問題。例如：
您的語言應該有一個正式的、定義明確的語法和語義。
該語言的解釋器應該包括解析器，它會拒絕除語言中語法上有效規范以外的所有內容。
可能的話，應該允許進行某些與環境有關的檢查，如類型檢查。
請注意，這不是一個詳盡的清單；還有許多其它注意事項。
某些人喜歡忽略其中一些步驟，即，不用太擔心只接受語法上有效的代碼。這是很普遍的。通常的結果是：很難跟蹤這些語言的配置腳本中確實會突然出現的許多錯誤。（在我所寫的“破壞者數據錯誤模式”一文中討論了這一問題；請參閱 參考資料。）
遺憾的是，忽略這些步驟而產生的問題不僅僅是錯誤。一些最有破壞性的計算機安全性攻擊（包括“紅色代碼（Code Red）”病毒）都是因未能正確解析輸入而引起的。Ross Anderson 的 Security Engineering一書（請參閱 參考資料）包括了大量關於操作系統的環境中這樣的攻擊的討論。
使用 XML 的優點
幸運的是，成功設計這樣的語言已不再象以前那樣困難了。XML 是用來實施這一任務的絕好工具，因為有許多現成的 XML 解析器和開發工具。
這些第三方組件不僅可以使您的工作更簡便，而且還使開發人員能夠更方便地將您的配置腳本重用於其它應用程序。例如，可以為藥品大全應用程序編寫各種分子的 XML 描述，然後可以（由無權訪問原始應用程序的源代碼的另一方）將這些描述重用於藥品設計開發工具中。
順便提一下，以這種方式重用代碼也是必須很好定義配置語言的語義的另一個原因。如果程序的含義只能通過挖掘解釋器的詳細信息來確定，則重用腳本的花費會高得多。請參閱 參考資料，那裡有幾個非常好的 XML 工具的鏈接。
使用 XML 的缺點
使用 XML 存在一些缺點。用 XML 編寫的腳本非常冗長，而且對某些形式的信息（如可執行代碼）編碼會很笨拙。同樣，使用 XML 工具需要一些資源上的開銷和投資，在某些情況下，這些開銷和投資可能過多。在這樣的情況下，我更願意使用 S 表達式（S-expressions）作為語言的元級別（meta-level)語法。
S 表達式：XML 的替代方式
S 表達式是僅用一種形式的括號完全括起來的表達式。其名稱源於編程語言 Scheme（對，“S”表示“Scheme”）。
所有 Scheme 程序都由 S 表達式構成。Scheme 和其它類似 Lisp 的語言最初都是由 AI 社區設計的，以便於由用語言本身的程序反身處理（reflective processing）語言。但是，使用 S 表達式的許多優點並不依賴於處理語言 ― 使用任何語言（包括 Java 語言）也可以簡單地處理這些表達式。
待續
現在，如果您記得以下內容，源代碼的可用性在實現可擴展性的過程中應該不是太大的障礙：
如何識別配置腳本
如何選擇合適的配置
如何識別哪些環境需要黑盒
如何確定可擴展版本的復雜性
當提供配置語言時，您實際在構建一種語言
下一次，我將演示配置語言的一個簡單示例，它由 S 表達式構成，並有一個針對該語言的 Java 解釋器。
