【51CTO.com 5月24日外電頭條】我們建立的開發(fā)網(wǎng)站kalistick算是個(gè)Java專營店了，從一開始的***版起，全部產(chǎn)品使用的都是Java代碼，但我們并不偏執(zhí)，從2008年開始，我們也開始分析和使用C#。我注意到Java開發(fā)者大都在看待C#的時(shí)候多少帶些輕蔑，就好像這是一只微軟仿造的山寨貓，蠢人和軟蛋們才會用它。我在博客中開始清除這些觀念和誤解，展示C#的種種好處。

Java和C#的相同之處比不同處要多得多：兩種語言都是寫在大括號里的，就像C和C++，類型都是靜態(tài)、強(qiáng)類型和顯式形態(tài)，兩種語言都是基于類的面向?qū)ο笳Z言，兩者用的都是運(yùn)行時(shí)編譯的思路，并且很好的使用了垃圾處理。

所以這篇文章里，我要重點(diǎn)談?wù)勊鼈兊南嗤c(diǎn)，以及C#的巧妙之處。

51CTO推薦專題：Visual Studio進(jìn)化史

統(tǒng)一類型系統(tǒng)(Unified type system)

在Java中，原始數(shù)據(jù)類型(byte、int、bool、float、char等)和其他的類不同，它們并不算是面向?qū)ο?，也不和引用類型共享相同的祖先類，但它們是有自己的包裝類的，用來代表自己并且用來插入到對象結(jié)構(gòu)中(例如int使用Integer類)，這樣做可以提高性能。

在另一邊，C#的統(tǒng)一類型系統(tǒng)卻都是從一個(gè)公用的根類型System.Object類中衍生而來的，即使是原始數(shù)據(jù)類型。所有的數(shù)據(jù)都要用到對象方法(ToString、Equal、GetHashCode等)，所以你會碰上像3.ToString()這樣的表達(dá)式，這種把方法混合到后綴，就帶來了dsl風(fēng)格的語句：

TimeSpan workingTime = 7.Hours() + 30.Minutes(); 

這么做的美妙之處在于當(dāng)開發(fā)者把數(shù)據(jù)類型當(dāng)做值來使用時(shí)，它們能夠和Java的原始類型一樣高效，只有在想要把它們當(dāng)做對象使用時(shí)，系統(tǒng)才需要使用boxing/unboxing來分配堆內(nèi)存。

顯式虛方法(Explicit virtual method)

在Java中，默認(rèn)所有的方法都是虛方法(雖然這些方法可以使用final封裝起來而不允許覆蓋)，而C#則不同，如果想在C#中寫一個(gè)虛方法，必須先要用virtual關(guān)鍵字顯式聲明一下。

有幾種原因決定了這樣的選擇，首先是性能上的考慮：虛方法都有一個(gè)懸在頭上的性能問題，因?yàn)樗鼈儾皇钦５膬?nèi)聯(lián)，需要通過vtable來進(jìn)行調(diào)用，這種做法并不直接(Sun的JVM可以內(nèi)聯(lián)上最經(jīng)常調(diào)用的虛方法)。第二個(gè)也是更重要的原因就是版本問題：C#的設(shè)計(jì)思路是向后兼容，因此不同版本類庫中的基類和衍生類是可以進(jìn)化發(fā)展和保持兼容的。例如，C#能夠完全支持基類中新加入的成員和衍生類中的成員同名，而不會導(dǎo)致無法預(yù)料的錯(cuò)誤。***一點(diǎn)是可讀性：開發(fā)者的編程意圖能夠非常明顯的讀出來。在Java中，如果開發(fā)者不寫出Override annotation的話，你不會知道他到底是不是想要重寫這個(gè)方法。

class Meme 
{ 
public virtual void Spread() {} 
} 
class ThreeHundred : Meme 
{ 
public override void Spread() 
{ 
Console.Write("This is sparta!"); 
} 
} 
class Dbz: Meme 
{ 
// Not a method override 
public void Spread() 
{ 
Console.Write("It's over nine thousaaannnd!"); 
} 
} 

真正的泛型(True Generic)

關(guān)于泛型，Java和C#顯示出語法上的相似性，但真正深入理解之后你會發(fā)現(xiàn)這兩種語言在泛型處理上的差別很大。

Java的泛型是在編譯器中處理的，運(yùn)行時(shí)并不關(guān)心泛型類型。Java在編譯中使用叫做類型擦除轉(zhuǎn)換的泛型類與方法：所有的泛型類型都被它們的原始版本替換，并且會在客戶代碼中插入cast和類型檢查，生成的字節(jié)代碼中并不包含任何泛型類型或參數(shù)的引用。Java的泛型是讓你在語法編寫上嘗到甜頭，但不會讓你的應(yīng)用執(zhí)行起來更有效。

而C#的泛型并不全是語言上的功能，它是放置在CLR(Common Language Runtime, 相當(dāng)于JVM)中的。在編譯時(shí)需要進(jìn)行泛型類型檢查驗(yàn)證，但指定類型會推遲到類裝載時(shí)生成。代碼調(diào)用時(shí)的泛型是完全編譯的，而且可以假設(shè)泛型在類型上是安全的，這被稱為泛型的具體化。和Java不同，C#不需要插入cast或者類型檢查。泛型類型和方法可以通過引用(class、delegate、interface等)和值類型(primitive type、struct、enum等)來創(chuàng)建。

C#中泛型的使用能夠帶來效率的提高(不需要cast和值類型的boxing/unboxing)，還能夠提高深層次的安全驗(yàn)證和反映能力。

public void AwesomeGenericMethod(T t) where T : new() 
{ 
  T newInstance = new T (); // Causes a type creation error in Java 
  T[] array = new T [0]; // Causes generic array creation error in Java 
  T defaultValue = default(T); 
  Type type = typeof(T); 
  List list = new List (); 
} 
// Generic with same name but a different number of generic type 
public void AwesomeGenericMethod(T t, U u) where T : new() 
{ 
} 

Oracle的Java平臺總架構(gòu)師Mark Reinhold在Devoxx 2011大會上曾經(jīng)探討過給Java添加泛型的具體化問題，但這項(xiàng)功能還沒有規(guī)劃進(jìn)Java的下一個(gè)主要版本中。

告別被檢查異常(checked exception)

Java和C#的異常檢查工作差不多一樣，二者唯一的主要區(qū)別是：Java中包含了checked exception這樣的異常。在Java里你可以在方法聲明中拋出ExceptionType，這樣做可以強(qiáng)迫任何調(diào)用方法的函數(shù)來處理異常。這個(gè)想法在紙面上說說很好，但實(shí)際使用中卻很煩人，而且?guī)砹诵聠栴}。

版本問題：在新版本的方法聲明中加入一個(gè)checked exception會破壞客戶代碼，就像給一個(gè)接口添加方法一樣。比如在版本1中你創(chuàng)建了一個(gè)foo方法，聲明拋出異常A和B，在版本2中你添加了一些新功能，拋出異常D，這就是一個(gè)破壞性變化，因?yàn)楝F(xiàn)有的調(diào)用程序不能處理這個(gè)異常。

擴(kuò)展性問題：在大規(guī)模的應(yīng)用項(xiàng)目中，相互依賴的工作是非常多的，因此拋出的異常會多的難以統(tǒng)計(jì)，開發(fā)者經(jīng)常會繞開掉這個(gè)功能，通過拋出泛型異常或者使用空的catch塊。

checked exception背后的思路是了不起的，但是尤其在大項(xiàng)目中，它有點(diǎn)太強(qiáng)迫性了。這就是C#為什么不使用checked exception的原因，其他主流語言也一樣：留給開發(fā)者自己處理。

訪問器和修改器

Java的訪問器和修改器(getAddress、setAddress、isValid等)使用命名慣例。而在C#中，訪問器和修改器是內(nèi)置的，自身帶有屬性，不需要再寫getter和setter，所有的工作看上去都是直來直去，即使內(nèi)部并不是這樣的機(jī)制(許多其他語言也是這樣)。

class Meme 
{ 
  // A private backing field is created by the compiler 
  public string CatchPhrase { get; set;} 
  public string URL { get; set;} 
} 
Meme meme = new Meme(); 
meme.CatchPhrase = "Rick roll'd"; 
meme.URL = "http://www.youtube.com/watch?v=EK2tWVj6lXw"; 
// Equivalent in Java 
class Meme 
{ 
  private String catchPhrase; 
  private String url; 
  public String getCatchPhrase() 
  { 
    return catchPhrase; 
  } 
  public void setCatchPhrase(String catchPhrase) 
  { 
    this.catchPhrase = catchPhrase; 
  } 
  public String getUrl() 
  { 
    return url; 
  } 
  public void setUrl(String url) 
  { 
    this.url = url; 
  } 
} 

當(dāng)你聲明一個(gè)屬性為自動(dòng)執(zhí)行時(shí)，編譯器會創(chuàng)建一個(gè)私有的匿名域，只有這個(gè)屬性的get和set訪問器可以讀取。這帶來了兼容性，即使是在類的內(nèi)部這個(gè)域也總是通過訪問器使用，這看上去干凈簡練。

C#中有一類訪問器是Java中沒有的：索引器(indexer)，它就像帶有參數(shù)的get和set。C#中的collection類比如Dictionary(和Java Map相類似)使用indexer。

var keywordsMapping = new Dictionary<string, string>(); 
keywordsMapping["super"] = "base"; 
keywordsMapping["boolean"] = "bool"; 
Console.Write("Java => C# : {0} => {1}", "super", keywordsMapping["super"]); 

你可能會說，沒問題吧，這不就是寫了一個(gè)初始化函數(shù)嗎?

因?yàn)榻?jīng)常要?jiǎng)?chuàng)建對象，然后初始化，這些可以用構(gòu)造器來完成，要不然在創(chuàng)建對象之后你就要調(diào)用不同的set方法。

而對象的索引器可以在創(chuàng)建對象時(shí)就把值分配給對象的各種可以訪問的域或?qū)傩?，這樣就不需要調(diào)用構(gòu)造器了。

Meme leeroy = new Meme { 
    CatchPhrase = "Leeroy Jenkins", 
    URL = "http://www.youtube.com/watch?v=LkCNJRfSZBU" 
}; 

在collection類中也可以使用。

List<int> digits = new List<int> { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }; 
Dictionary<string, string> keywordsMapping = new Dictionary<string, string>() { 
    {"super", "base"}, 
    {"boolean", "bool"}, 
    {"import", "using"} 
}; 

逐字字符串(Verbatim string)

從字符串中把字符分解出來是非常痛苦的工作，尤其是混合著不同含義的正則表達(dá)式。C#的逐字字符串允許反斜杠、制表符、引號和換行符作為字符串的一部分，不再需要轉(zhuǎn)義字符。

string pattern = @"d{3}-d{3}-d{4}"; 
string input = @"Multiline string 
   325-532-4521"; 
Regex.IsMatch(input, pattern, RegexOptions.Multiline); 

總結(jié)

通過本文我想說C#不僅和Java很相像，而且它能夠讓開發(fā)者的生活變得更輕松，能夠?qū)嵲诘臏p輕他們的負(fù)擔(dān)(其他語言也一樣)，即使這是一只山寨貓，那么它做的也是相當(dāng)不錯(cuò)。

實(shí)際上Java開發(fā)者們也做出了相似的回應(yīng)，有些運(yùn)行在JVM上的腳本語言例如Groovy就提供了這里說到的大多數(shù)功能，但Java本身還略顯頑固，沒有做出改變。

原文地址：

http://blog.kalistick.com/java/why-java-folks-should-stop-looking-down-on-c-differences-in-similarities/