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

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

Microsoft 對因特網(wǎng)的新視野與當今在線內(nèi)容的網(wǎng)絡相去甚遠。Microsoft 預見未來的因特網(wǎng)是一個由不同的人用不同的語言在不同的硬件平臺上開發(fā)出的互相關聯(lián)的服務，可以被運行在不同的因特網(wǎng)操作系統(tǒng)之上。

該公司為大膽設想的這個新世界所提供的就是 .Net 平臺。實際上，.Net 并不是傳統(tǒng)意義上的平臺；它并不是一種公共的硬件或軟件系統(tǒng)。.Net 實際上是一個協(xié)議集合，它允許因特網(wǎng)應用程序利用運行在不同機器上的不同服務。

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

非他莫屬：Anders Hejlsberg，語言體系結(jié)構(gòu)設計師

考慮一下 Hejlsberg 的經(jīng)歷，就不會奇怪 Microsoft 將此重任交給他了。畢竟，C# 將不是他對軟件開發(fā)方式的首次大事改革。

作為 Borland 的首席體系結(jié)構(gòu)設計師，Hejlsberg 秘密地將 Turbo Pascal 變成一種面向?qū)ο蟮摹碛姓嬲梢暬沫h(huán)境和卓越的數(shù)據(jù)庫訪問特性的應用程序開發(fā)語言。曾經(jīng)被吹捧為“VB 殺手”的 Delphi 依然是 Borland（現(xiàn)在為 Inprise/Borland）的拳頭產(chǎn)品。

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

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

Hejlsberg 對 Microsoft 的 Java 產(chǎn)品的更改促使 Sun 控告 Microsoft 違反了 Java 許可協(xié)議。Sun 聲稱，Visual J++ 語言擴展沒有保持 Java 的平臺中立性，而是將開發(fā)人員鎖定在 Microsoft 平臺上。盡管 Microsoft 的 Visual J++ 事實上是最好的 Java 編譯器，并且該公司的虛擬器（執(zhí)行 Java 字節(jié)碼的運行期模塊）是最快的一種虛擬機，但 Sun 的訴訟已有效地阻止了 Microsoft 在 Java 舞臺中的競爭。

Microsoft 的反應是完全從 Java 中退出來，并用一種新的基礎因特網(wǎng)平臺 — .Net — 和一種新的旗幟語言 — C# 來取代它。Anders Hejlsberg 是完成后一工作的自然選擇。

證明一種新編程語言的合理性

最近有關 C# 爭論 的一些新聞聲稱開發(fā)人員還不會收受另一種編程語言。雖然現(xiàn)在確實已經(jīng)有幾種有用的語言可供開發(fā)人員使用，但仍有空間容納另一種語言 — 假如它填補了仍未滿足的需要。一種新的語言畢竟只是專業(yè)人員可用來創(chuàng)建軟件解決方案的另一種工具。讓我們分析一下 Microsoft 為 C# 制定的目標，以及其他語言到目前為止還沒有滿足這些目標的情況。

快速應用程序開發(fā)：Microsoft 為 C# 制定的最重要的目標之一就是支持 RAD。因特網(wǎng)應用程序必須以因特網(wǎng)節(jié)奏開發(fā)；一種新語言必須易于學習和調(diào)試，而且必須生成易于更新的代碼。雖然 Delphi 和 VB 在這些方面很出色，但 C++ 卻沒有這么成功。語言本身復雜而難以掌握，而且很少有有用的 C++ 庫提供簡單的接口。此外，C++ 的手動內(nèi)存管理和復雜的類型轉(zhuǎn)換模型使它難以調(diào)試。

此外，正如我們將在下面看到的那樣，C++ 本質(zhì)上不防止由于版本不兼容而導致的潛在問題。盡管 Microsoft 和 Borland 對這種語言作了巨大的努力，但 C++ 仍然不適合快速應用程序開發(fā)。

跨平臺部署：根據(jù)定義，因特網(wǎng)語言應該支持跨平臺的部署。因為因特網(wǎng)是不同系統(tǒng)的一個網(wǎng)絡，所以必須將服務部署到各式各樣的硬件和軟件上。 此外，客戶端軟件應該能夠運行在多種類型的設備上，包括 PDA 和蜂窩式便攜無線電話。 這種靈活性事實上是對除 Java 之外的所有語言的一種挑戰(zhàn)。VB 尤其只能生成在基于 Intel 微處理器的機器上運行的 Windows 應用程序。Delphi 也受到同樣的限制。Delphi for Linux 不久就會發(fā)布，但它也不支持因特網(wǎng)設備。VB 和 Delphi 都不符合跨平臺部署的目標。

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

支持 COM 和 .Net 平臺：Microsoft 已將支持 COM 和 .Net 平臺確定為 C# 的最重要的目標。當然，目前還沒有一種語言支持 .Net 平臺，因為它仍在構(gòu)建中。與 .Net 不同，COM 已出現(xiàn)相當一段時間了，但它仍然缺少強大的語言支持。大多數(shù)語言，包括 C++ 和 Delphi，都要求開發(fā)人員為他們所創(chuàng)建的每個 COM 對象創(chuàng)建一個額外的 IDL 聲明、一個類工廠和專用的修飾。

某些語言廠商已提供了一些向?qū)碜詣油瓿稍S多常見的 COM 和 OLE 任務，但這些工具沒有完全隱藏 COM 的復雜性。VB 確實成功隱藏了 COM 的復雜性，但這是以犧牲功能為代價換來的。VB 不僅缺乏面向?qū)ο笳Z言的力量；它也無法支持 COM 的低級功能 — 例如，多個接口、聚集和自定義編排。簡而言之，沒有一種現(xiàn)有的語言像 C# 那樣全面支持 COM。

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

C# 是一種 RAD 環(huán)境

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

C# 實現(xiàn)了 Java 和 Delphi 風格的值/引用類型系統(tǒng)：為了進一步支持 RAD，C# 始終以 Java 和 Delphi 風格的值/引用類型系統(tǒng)處理 C/C++ 指針模型。在這個系統(tǒng)中，內(nèi)建類型（integer、real、string，等等）、枚舉 (enumeration) 和結(jié)構(gòu) (structure) 都是值類型。賦值運算符和比較運算符復制并檢查這些類型的變量的值。接口、類和授權(quán)（將在后面說明）都是引用類型。賦值運算符和比較運算符復制并檢查這些類型的變量所引用的對象的同一性。

這種值/引用類型系統(tǒng)比 C++ 的指針模型要簡單得多。它使對象處理更加容易，并消除了困擾 C 和 C++ 程序的許多內(nèi)存錯誤。

C# 接口是獨立于類來聲明的：C# 也支持類似 Java 和 Delphi 的接口模型，接口是獨立于類來聲明的。這與 C++ 模型是對立的，在 C++ 中接口實際上就是抽象基類。接口和類都可以繼承多個接口。而類可以繼承一個基類，接口根本不能繼承類。這種模型避免了 C++ 的多繼承問題，C++ 中不同基類中的實現(xiàn)可能出現(xiàn)沖突。因此也不再需要諸如虛擬繼承和顯式作用域這類復雜機制。C# 的簡化接口模型有助于加快應用程序的開發(fā)。

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

C# 使用方法引用，稱為授權(quán)，而不使用方法指針：C# 使用方法引用來快速連接對象和方法。稱為授權(quán)的這些方法引用類似于 Delphi 的過程類型。Hejlsberg 也將同一機制引入 Visual J++ 6.0 中，不過它并不是標準 Java 規(guī)范的一部分。方法引用有點像 C++ 的方法指針，但它要優(yōu)越、安全和有用得多。

授權(quán)是一種引用類型，它持有方法的簽名。 應用程序可將符合這一簽名的任何方法賦給授權(quán)變量。當調(diào)用這種授權(quán)變量時，相關的方法就會被調(diào)用。與 Delphi 的過程類型不同，C# 授權(quán)自動支持多點傳送。應用程序可以將許多方法賦給一個授權(quán)變量；當調(diào)用此變量時，所有方法都會被調(diào)用。

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

顯式的重載聲明：最后，C# 使用顯式的重載聲明來支持 RAD。顯式的重載聲明通過保護類的方法名稱空間并指出意外的命名沖突來支持快速應用程序開發(fā)。

C# 導出類的開發(fā)人員必須顯式地用關鍵字 override 標記方法重載，正像在 Delphi 中所做的那樣。如果導出類包含一個與基類中的一個虛方法同名的未標記方法，則編譯器無法明確辨別作者的意圖。

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

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

C# 的其他特性

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

跨平臺部署：C# 以 Java 解決這一問題的相同方式解決了跨平臺部署的問題。C# 編譯器生成由 .Net 運行時解釋的字節(jié)碼流。運行時組件的工作方式與 Java 虛擬機十分類似；應用程序可以部署到已安裝了 .Net 運行時的任何設備上。

應用程序?qū)ζ脚_固有資源的訪問：與 Java 虛擬機不同，.Net 運行時允許程序訪問平臺固有的資源。 例如，一個 C# 程序可以利用 Windows API 作為 Windows 2000 上全功能的應用程序運行。通過使用 Windows CE API 子集，同一個程序也可以在 PDA 上運行。 當然，并不是應用程序預期的所有服務都可在所有設備上獲得。因此在所有目標平臺上測試軟件是開發(fā)人員的責任，如有必要，開發(fā)人員還可以編寫特殊情況的代碼，那將使系統(tǒng)在缺少所需的服務時仍能夠工作。

支持 COM 和 .Net：為了支持 COM 和 .Net 平臺，C# 包含一種稱為屬性的獨特語言特性。一個屬性實際上就是一個 C# 類，它通過修飾源代碼來提供元信息。屬性使 C# 能夠支持特定的技術，如 COM 和 .Net，而不會干擾語言規(guī)范本身。

例如，C# 提供將 C# 接口轉(zhuǎn)換為 COM 接口的屬性類。另一些屬性類將 C# 類轉(zhuǎn)換為 COM 類。執(zhí)行這些轉(zhuǎn)換不需要任何 IDL 或類工廠。某些語言觀察家聲稱所有 C# 類都是 COM 對象。這不正確 — 但通過合適的屬性，任何 C# 類很容易轉(zhuǎn)換為一個 COM 對象。

隨編譯器提供的另一個屬性庫將 C# 類和函數(shù)包裝為 Web 服務。Web 服務是可在因特網(wǎng)上通過交互協(xié)議（如 SOAP）調(diào)用的托管軟件模塊。SOAP 將方法調(diào)用與它們的參數(shù)和返回值一起包裝在 XML 數(shù)據(jù)包中。Web 服務可用許多語言編寫，并可部署到許多硬件和軟件平臺上。而且，不同類型的 Web 服務可以協(xié)作組成整個 Web 應用程序。通過使用正確的屬性，程序員很容易將任何 C# 類或函數(shù)轉(zhuǎn)換為 Web 服務。

C# 不具備的特性

與 Anders Hejlsberg 的經(jīng)歷一致，C# 用來支持因特網(wǎng)應用程序的許多特性是從 Delphi 和 Java 挑選而來的。而 Microsoft 聲稱 C# 是從 C 和 C++ 轉(zhuǎn)變而來的。因此讓我們分析一下 C# 不具備的某些 C++ 特性。

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

引用聲明語法：因為類、接口和授權(quán)類型默認情況下都是引用，所以 C# 沒有 C++ 的引用聲明語法。這種新語言改為使用類似于 Delphi 聲明按引用傳遞參數(shù)的語法：

無標記的參數(shù)是輸入?yún)?shù)

ref 關鍵字指定一個輸入/輸出參數(shù)（類似于 Delphi 的 var）

out 關鍵字指定一個輸出參數(shù)

params 關鍵字指定一個變長參數(shù)列表（類似于 Delphi 的 variant open-array 參數(shù)）

模板：與 Java 和 Delphi 一樣，C# 沒有模板。因此，C# 沒有支持聲明類型安全的集合的機制。每個類最終都是從共同的基類 object 導出的。一般集合類必須是一個 object 集合，需要將它的成員不安全地下溯類型轉(zhuǎn)換為所需的類型。

盡管沒有 C++ 的這些語言特性，但 C# 仍然是一種功能強大的編程語言，圍繞類似 Java 和 Delphi 的特性進行設計來支持因特網(wǎng)應用程序。因為 C++ 對機器級的關注以及缺少 RAD 支持，所以它不適合用作因特網(wǎng)應用程序開發(fā)語言的基礎。如果 C++ 開發(fā)人員需要針對 .Net 平臺編寫應用程序和服務，則在 C# 發(fā)布以后將會被極力建議學習這種語言 — 請記住，它與 C++ 的實際區(qū)別比它們的名稱所表明的區(qū)別要大得多。

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

作者簡介

Michael L. Perry 六年多來一直從事專業(yè) Windows 開發(fā)，并擁有 COM+、Java、XML 等方面的專家經(jīng)驗以及目前塑造編程前景的其他技術。他于 1998 年成立了 Mallard Software Designs 公司，在公司內(nèi)他用數(shù)學嚴格證明軟件設計 — 在實現(xiàn)之前首先建立解決方案的正確性。