轉重粒子空間：C#，自然的進步

C#，自然的進步
隨著 Visual J++ 的隱退，Microsoft 引入 C# 來填補這一空白

Michael L. Perry
Mallard 軟體設計師
2000 年 8 月

Microsoft 對網際網路的新視野與當今線上內容的網路相去甚遠。Microsoft 預見未來的網際網路是一個由不同的人用不同的語言在不同的硬體平台上開發出的互相關聯的服務，可以被運行在不同的網際網路作業系統之上。

該公司為大膽設想的這個新世界所提供的就是 .Net 平台。實際上，.Net 並不是傳統意義上的平台；它並不是一種公用的硬體或軟體系統。.Net 實際上是一個協議集合，它允許網際網路應用程式利用運行在不同機器上的不同服務。

Microsoft 新戰略的結果就是下一代的 Microsoft Visual Studio 將有重新設計的語言，尤其是能支援 .Net 平台。Java 將不再此程式包中，Visual J++ 也不會再有新的版本。不要擔心，Microsoft 將推出一個新的語言 C# 來填補這一空白。該公司動用了其最好的資源，包括星級語言專家 Anders Hejlsberg，來開發 C#。

非他莫屬：Anders Hejlsberg，語言體繫結構設計師
考慮一下 Hejlsberg 的經曆，就不會奇怪 Microsoft 將此重任交給他了。畢竟，C# 將不是他對軟體開發方式的首次大事改革。

作為 Borland 的首席體繫結構設計師，Hejlsberg 秘密地將 Turbo Pascal 變成一種物件導向的、擁有真正可視化的環境和卓越的資料庫訪問特性的應用程式開發語言。曾經被吹捧為“VB 殺手”的 Delphi 依然是 Borland（現在為 Inprise/Borland）的拳頭產品。

Microsoft 用豐厚的薪水、股票認購權和巨額的加盟獎金雇請了 Hejlsberg 之後，Borland 曾提出通過不正當手段吸收新成員的控告。Borland 還曾聲稱 — 提供了很少的細節來支援指控 — Hejlsberg 正在開發“Delphi for Java”。這場訴訟最終以 Borland 的勝利而收場；但是從那時起，Microsoft 已在讓 Hejlsberg 工作了。

Hejlsberg 充實了 Microsoft 的 Java 產品；其中格外引人注意的是，為了跟上其他 Visual Studio 語言的現行版本號碼，他人為地在一個發行版中將其版本號碼從 1.1 提升到 6.0。實際上，這個版本號碼的跳躍並未誇大 6.0 與其前一版本之間的差別。Hejlsberg 添加的功能已使該語言變成一種強大的 Windows 應用程式開發平台。添加的功能包括對 Windows API 的訪問；因此，利用這些新功能的程式不再具有可移植性。

Hejlsberg 對 Microsoft 的 Java 產品的更改促使 Sun 控告 Microsoft 違反了 Java 許可協議。Sun 聲稱，Visual J++ 語言擴充沒有保持 Java 的平台中立性，而是將開發人員鎖定在 Microsoft 平台上。儘管 Microsoft 的 Visual J++ 事實上是最好的 Java 編譯器，並且該公司的虛擬器（執行 Java 位元組碼的運行期模組）是最快的一種虛擬機器，但 Sun 的訴訟已有效地阻止了 Microsoft 在 Java 舞台中的競爭。

Microsoft 的反應是完全從 Java 中退出來，並用一種新的基礎網際網路平台 — .Net — 和一種新的旗幟語言 — C# 來取代它。Anders Hejlsberg 是完成後一工作的自然選擇。

證明一種新程式設計語言的合理性
最近有關 C# 爭論 的一些新聞聲稱開發人員還不會收受另一種程式設計語言。雖然現在確實已經有幾種有用的語言可供開發人員使用，但仍有空間容納另一種語言 — 假如它填補了仍未滿足的需要。一種新的語言畢竟只是專業人員可用來建立軟體解決方案的另一種工具。讓我們分析一下 Microsoft 為 C# 制定的目標，以及其他語言到目前為止還沒有滿足這些目標的情況。

快速應用程式開發：Microsoft 為 C# 制定的最重要的目標之一就是支援 RAD。網際網路應用程式必須以網際網路節奏開發；一種新語言必須易於學習和調試，而且必鬚生成易於更新的代碼。雖然 Delphi 和 VB 在這些方面很出色，但 C++ 卻沒有這麼成功。語言本身複雜而難以掌握，而且很少有有用的 C++ 庫提供簡單的介面。此外，C++ 的手動記憶體管理和複雜的類型轉換模型使它難以調試。
此外，正如我們將在下面看到的那樣，C++ 本質上不防止由於版本不相容而導致的潛在問題。儘管 Microsoft 和 Borland 對這種語言作了巨大的努力，但 C++ 仍然不適合快速應用程式開發。



跨平台部署：根據定義，網際網路語言應該支援跨平台的部署。因為網際網路是不同系統的一個網路，所以必須將服務部署到各式各樣的硬體和軟體上。 此外，用戶端軟體應該能夠運行在多種類型的裝置上，包括 PDA 和蜂窩式便攜無線電話。 這種靈活性事實上是對除 Java 之外的所有語言的一種挑戰。VB 尤其只能產生在基於 Intel 微處理器的機器上啟動並執行 Windows 應用程式。Delphi 也受到同樣的限制。Delphi for Linux 不久就會發布，但它也不支援網際網路裝置。VB 和 Delphi 都不符合跨平台部署的目標。


訪問平台固有的資源：據 Microsoft 稱，開發人員需要訪問平台固有的資源。對於編寫強大的目標應用程式而言，這種訪問有時是必不可少的。Visual J++ 6.0 允許開發人員訪問 Windows API，Java 通常不允許這種訪問。Java 通過定義每種虛擬機器實現的最小公分母標準來提供跨平台的部署。Java 開發人員依據這種削弱的標準編寫代碼，而不能利用只有某些平台才提供的更強大的服務。這樣，Java 無法滿足提供對平台固有資源的訪問這一目標。


支援 COM 和 .Net 平台：Microsoft 已將支援 COM 和 .Net 平台確定為 C# 的最重要的目標。當然，目前還沒有一種語言支援 .Net 平台，因為它仍在構建中。與 .Net 不同，COM 已出現相當一段時間了，但它仍然缺少強大的語言支援。大多數語言，包括 C++ 和 Delphi，都要求開發人員為他們所建立的每個 COM 物件建立一個額外的 IDL 聲明、一個類工廠和專用的修飾。
某些語言廠商已提供了一些嚮導來自動完成許多常見的 COM 和 OLE 任務，但這些工具沒有完全隱藏 COM 的複雜性。VB 確實成功隱藏了 COM 的複雜性，但這是以犧牲功能為代價換來的。VB 不僅缺乏物件導向語言的力量；它也無法支援 COM 的低級功能 — 例如，多個介面、聚集和自訂編排。簡而言之，沒有一種現有的語言像 C# 那樣全面支援 COM。

雖然這四個目標對於一種新語言是相當高的，但 Hejlsberg 在工作中已拿出自己最好的經驗來確保 C# 實現這些目標。結果是產生了一種語言，這種語言從 Java 和 Delphi 中借鑒東西與從 C 和 C++ 借鑒的東西一樣多（如果沒有超過的話）。請注意，下面的資訊基於 C# 操作規程，可能不準確代表最終的產品發行版。

C# 是一種 RAD 環境

C# 提供 Java 風格的垃圾收集：C# 提供的最重要的 RAD 功能之一就是 Java 風格的垃圾收集。在運行時的任意時間內，所有沒有引用的對象會自動刪除。通過將開發人員從手動記憶體管理工作中解放出來，垃圾收集使程式開發變得容易且不易出錯。但是，自動垃圾收集是耗時的，並且是不可預知的。因此，C# 允許開發人員在要求即時效能的情況下局部禁用垃圾收集 — 通過將代碼標記為 unsafe。


C# 實現了 Java 和 Delphi 風格的值/參考型別系統：為了進一步支援 RAD，C# 始終以 Java 和 Delphi 風格的值/參考型別系統處理 C/C++ 指標模型。在這個系統中，內建類型（integer、real、string，等等）、枚舉 (enumeration) 和結構 (structure) 都是實值型別。賦值運算子和比較子複製並檢查這些類型的變數的值。介面、類和授權（將在後面說明）都是參考型別。賦值運算子和比較子複製並檢查這些類型的變數所引用的對象的同一性。
這種值/參考型別系統比 C++ 的指標模型要簡單得多。它使對象處理更加容易，並消除了困擾 C 和 C++ 程式的許多記憶體錯誤。



C# 介面是獨立於類來聲明的：C# 也支援類似 Java 和 Delphi 的介面模型，介面是獨立於類來聲明的。這與 C++ 模型是對立的，在 C++ 中介面實際上就是抽象基類。介面和類都可以繼承多個介面。而類可以繼承一個基類，介面根本不能繼承類。這種模型避免了 C++ 的多繼承問題，C++ 中不同基類中的實現可能出現衝突。因此也不再需要諸如虛擬繼承和顯式範圍這類複雜機制。C# 的簡化介面模型有助於加快應用程式的開發。


類方法的聲明和定義被組合在一起：C# 簡化開發的另一個方面是將類方法的聲明和定義組合在一起，與 Java 的做法十分類似。 C++ 開發人員必須為聲明（標頭檔）和定義（實現檔案）維護單獨的檔案，結果使得軟體開發過程變得複雜。C# 甚至能夠自動找出原始碼模組之間的關係，從而使開發人員從一項附加的雜務中解脫出來。儘管 C++ 需要使用 #include（Delphi 需要使用 uses）來定位相關的源檔案，但 C# 不需要任何額外的語句。


C# 使用方法引用，稱為授權，而不使用方法指標：C# 使用方法引用來快速連線物件和方法。稱為授權的這些方法引用類似於 Delphi 的過程類型。Hejlsberg 也將同一機制引入 Visual J++ 6.0 中，不過它並不是標準 Java 規範的一部分。方法引用有點像 C++ 的方法指標，但它要優越、安全和有用得多。
授權是一種參考型別，它持有方法的簽名。 應用程式可將符合這一簽名的任何方法賦給授權變數。當調用這種授權變數時，相關的方法就會被調用。與 Delphi 的過程類型不同，C# 授權自動支援多點傳送。應用程式可以將許多方法賦給一個授權變數；當調用此變數時，所有方法都會被調用。



C# 使用 Java 的簡單線程同步機制。要在 C# 中實現線程同步，開發人員只須對關鍵的代碼塊作標誌即可。 Java 開發人員使用 synchronized 關鍵字，而 C# 開發人員使用 lock。隱藏的互斥塊將帶有標誌的代碼塊封裝起來，在任一時刻只允許一個線程執行這段代碼。除了關鍵字不同之外，這一機制在 C# 和 Java 中是完全相同的。因為線程所有編程任務最容易出錯的一種，對同步進行簡化的任何特性都有助於快速應用程式開發。


顯式的重載聲明：最後，C# 使用顯式的重載聲明來支援 RAD。顯式的重載聲明通過保護類的方法名稱空間並指出意外的命名衝突來支援快速應用程式開發。
C# 匯出類的開發人員必須顯式地用關鍵字 override 標記方法重載，正像在 Delphi 中所做的那樣。如果匯出類包含一個與基類中的一個虛方法同名的未標記方法，則編譯器無法明確辨別作者的意圖。

另一方面，命名衝突可能是不可避免的；尤其是當基類和匯出類由不同的程式員（可能為不同的公司工作）實現時更是不可避免。在這種情況下，編譯器將發出一個警告，並將匯出類的方法視為一個新聲明，而不將其視為重載。

另一方面，如果程式員有意讓匯出類中的一個新方法與基類中的某個虛方法同名，則他（或她）可以使用 new 關鍵字來阻止編譯器發出警告。

C# 的其他特性
考慮一下剛剛討論過的的所有語言特性，對 RAD 的強大支援似乎是 Microsoft 為 C# 制定的一個最主要的目標。但是，C# 還必須致力於其他重要的開發需求。這些需求包括跨平台部署、訪問平台固有的資源和對 COM 和 .Net 平台的支援。讓我們分析一下旨在支援這些需求的 C# 語言特性。

跨平台部署：C# 以 Java 解決這一問題的相同方式解決了跨平台部署的問題。C# 編譯器產生由 .Net 運行時解釋的位元組碼流。運行時組件的工作方式與 JAVA 虛擬機器十分類似；應用程式可以部署到已安裝了 .Net 運行時的任何裝置上。


應用程式對平台固有資源的訪問：與 JAVA 虛擬機器不同，.Net 運行時允許程式訪問平台固有的資源。 例如，一個 C# 程式可以利用 Windows API 作為 Windows 2000 上全功能的應用程式運行。通過使用 Windows CE API 子集，同一個程式也可以在 PDA 上運行。 當然，並不是應用程式預期的所有服務都可在所有裝置上獲得。因此在所有目標平台上測試軟體是開發人員的責任，如有必要，開發人員還可以編寫特殊情況的代碼，那將使系統在缺少所需的服務時仍能夠工作。


支援 COM 和 .Net：為了支援 COM 和 .Net 平台，C# 包含一種稱為屬性的獨特語言特性。一個屬性實際上就是一個 C# 類，它通過修飾原始碼來提供元資訊。屬性使 C# 能夠支援特定的技術，如 COM 和 .Net，而不會干擾語言規範本身。
例如，C# 提供將 C# 介面轉換為 COM 介面的屬性類。另一些屬性類將 C# 類轉換為 COM 類別。執行這些轉換不需要任何 IDL 或類工廠。某些語言觀察家聲稱所有 C# 類都是 COM 物件。這不正確 — 但通過合適的屬性，任何 C# 類很容易轉換為一個 COM 物件。

隨編譯器提供的另一個屬性庫將 C# 類和函數封裝為 Web 服務。Web 服務是可在網際網路上通過互動協議（如 SOAP）調用的託管軟體模組。SOAP 將方法調用與它們的參數和傳回值一起封裝在 XML 資料包中。Web 服務可用許多語言編寫，並可部署到許多硬體和軟體平台上。而且，不同類型的 Web 服務可以協作組成整個 Web 應用程式。通過使用正確的屬性，程式員很容易將任何 C# 類或函數轉換為 Web 服務。

C# 不具備的特性
與 Anders Hejlsberg 的經曆一致，C# 用來支援網際網路應用程式的許多特性是從 Delphi 和 Java 挑選而來的。而 Microsoft 聲稱 C# 是從 C 和 C++ 轉變而來的。因此讓我們分析一下 C# 不具備的某些 C++ 特性。

範圍和非關聯化操作符：C# 不使用 C++ 範圍操作符 (::)；而是依賴於 Delphi 和 Java 中類似的點操作符 (.)。此外，因為它基於前面說明的 Java 和 Delphi 風格的值/參考型別系統，在大多數情況下 C# 不使用 C++ 的非關聯化訪問符 (->)，而是再次實現了點操作符。雖然重載的點操作符可能使剛開始學習 C# 的 C++ 程式員感到迷惑，但這對 Java 和 Delphi 開發人員來說是相當熟悉的。


引用聲明文法：因為類、介面和授與類型預設情況下都是引用，所以 C# 沒有 C++ 的引用聲明文法。這種新語言改為使用類似於 Delphi 聲明按引用傳遞參數的文法：
無標記的參數是輸入參數
ref 關鍵字指定一個輸入/輸出參數（類似於 Delphi 的 var）
out 關鍵字指定一個輸出參數
params 關鍵字指定一個變長參數列表（類似於 Delphi 的 variant open-array 參數）



模板：與 Java 和 Delphi 一樣，C# 沒有模板。因此，C# 沒有支援宣告類型安全的集合的機制。每個類最終都是從共同的基類 object 匯出的。一般集合類必須是一個 object 集合，需要將它的成員不安全地下溯類型轉換為所需的類型。
儘管沒有 C++ 的這些語言特性，但 C# 仍然是一種功能強大的程式設計語言，圍繞類似 Java 和 Delphi 的特性進行設計來支援網際網路應用程式。因為 C++ 對機器級的關注以及缺少 RAD 支援，所以它不適合用作網際網路應用程式開發語言的基礎。如果 C++ 開發人員需要針對 .Net 平台編寫應用程式和服務，則在 C# 發布以後將會被極力建議學習這種語言 — 請記住，它與 C++ 的實際區別比它們的名稱所表明的區別要大得多。

在這個過渡時期，最好學習 Java 或 Delphi。不僅因為這兩種語言將使您更好地理解 C#，而且因為這兩種語言本身也是非常有用的語言。作為軟體專業人員，我們應該利用可獲得的最好的工具。

作者簡介
Michael L. Perry 六年多來一直從事專業 Windows 開發，並擁有 COM+、Java、XML 等方面的專家經驗以及目前塑造編程前景的其他技術。他於 1998 年成立了 Mallard Software Designs 公司，在公司內他用數學嚴格證明軟體設計 — 在實現之前首先建立解決方案的正確性。