A Comparative Overview of C#中文版(二)

來源:互聯網
上載者:User
中文 在GameTest裡,我們分別建立了一個game和一個監視game的referee,然後,然後我們改變game的Score去看看referee對此有何反應。在這個系統裡,game沒有referee的任何知識,任何類都可以監聽並對game的score變化產生反應。關鍵字event隱藏了除了+=和-=之外的所有委託方法。這兩個操作符允許你添加(或移去)處理該事件的多個事件處理器。
【譯註:我們以下例說明後面這句話的意思:
public class Game
{
public event ScoreChangeEventHandler ScoreChange;
protected void OnScoreChange()
{
    if (ScoreChange != null) ScoreChange(30, ref true);//在類內,可以這麼使用
}
,但在這個類外,ScoreChange就只能出現在運算子+=和-=的左邊】
     你可能首先會在圖形化使用者介面架構裡遇到這個系統。game好比是使用者介面的某個控制項,它根據使用者輸入觸發事件,而referee則類似於一個表單,它負責處理該事件。
     【作者註:委託第一次被微軟Visual J++引入也是Anders Hejlsberg設計的,同時它也是造成Sun和微軟在技術和法律方面爭端的起因之一。James Gosling,Java的設計者,對Anders Hejlsberg曾有過一個故作謙虛聽起來也頗為幽默的評論,說他因為和Delphi藕斷絲連的感情應該叫他“方法指標先生”。在研究Sun對委託的爭執後,我覺得稱呼Gosling為“一切都是一個類先生”好像公平些J 過去的這幾年裡,在編程界,“做努力類比現實的抽象”已經被很多人代之以“現實是物件導向的,所以,我們應該用物件導向的抽象來類比它”。
     Sun和微軟關於委託的爭論可以在這兒看到:
http://www.Javasoft.com/docs/white/delegates.html http://msdn.microsoft.com/visualj/technical/articles/delegates/truth.asp 】
6.枚舉
     枚舉使你能夠指定一組對象,例如:
聲明:
public enum Direction {North, East, West, South};
使用:
Direction wall = Direction.North;
這真是個優雅的概念,這也是C#為什麼會決定保留它們的原因,但是,為什麼Java卻選擇了拋棄?在Java中,你不得不這麼做:
聲明:
public class Direction
{
    public final static int NORTH = 1;
    public final static int EAST = 2;
    public final static int WEST = 3;
    public final static int SOUTH = 4;
}
使用:
     int wall = Direction.NORTH;
看起來好像Java版的更富有表達力,但事實並非如此。它不是型別安全的,你可能一不小心會把任何int型的值賦給wall而編譯器不會發出任何抱怨【譯註:你顯然不可以這麼寫:Direction wall = Direction.NORTH;】。坦白地說,在我的Java編程經曆裡,我從未因為該處非型別安全而花費太多的時間寫一些額外的東西來捕捉錯誤。但是,能擁有枚舉是一件快事。C#帶給你的一個驚喜是—當你偵錯工具時,如果你在使用枚舉變數的地方設定斷點,調試器將自動譯解direction並給你一個可讀的資訊,而不是一個你自己不得不譯解的數值:
聲明:
public enum Direction {North=1, East=2, West=4, South=8};
使用:
Direction direction = Direction.North | Direction.West;
if ((direction & Direction.North) != 0)
//....
如果你在if語句上設定斷點,你將得到一個你可讀的direction而不是數值5。
【譯註:這個例子改一下,會更有助於理解:
聲明:
public enum Direction {North=1, East=2, West=4, South=8, Middle = 5/*注意此處代碼*/};
使用:
Direction direction = Direction.North | Direction.West;
if ((direction & Direction.North) != 0)
//....
如果你在if語句上設定斷點,你將得到一個你可讀的direction(即Middle)而不是數值5】
【作者註:枚舉被Java拋棄的原因極有可能是因為它可以用類代替。正如我上面提到的,單單用類我們不能夠象用別的概念一樣更好地表達某個特性。Java的“如果它可以用類處理,那就不引入一個新的結構”的哲學的優點何在?看起來最大的優點是簡單—較短的學習曲線,並且無需程式員去考慮做同一件事的多種方式。實際上,Java語言在很多方面都以簡化為目標來改進C++,比如不用指標,不用標頭檔,以及單根對象層次等。所有這些簡化的共性是它們實際上使得編程—唔—簡單了,可是,沒有我們剛才提到的枚舉、屬性和事件等等,反而使你的代碼更加複雜了】
7.集合和foreach語句
     C#提供一個for迴圈的捷徑,而且它還促進了集合類更為一致:
在Java或C++中:
1. while (! collection.isEmpty())
{
    Object o = collection.get();
    collection.next()
    //...
2. for (int i = 0; i < array.length; i++)
    //...
在 C#中:
1.  foreach (object o in collection)
    //...
2.  foreach (int i in array)
    //...
C#的for迴圈將工作於集合對象上(數組實現一個集合)。集合對象有一個GetEnumerator()方法,該方法返回一個Enumerator對象。Enumerator對象有一個MoveNext()方法和一個Current屬性。
8.結構
     把C#的結構視為使語言的類型系統更為優雅而不僅是一種“如果你需要的話可以利用之寫出真正有效率的代碼”的概念更好些。
     在C++中,結構和類(對象)都可分配在棧或堆上。在C#中,結構永遠建立在棧上,類(對象)則永遠建立在堆上。使用結構實際上可以產生更有效率的代碼:
public struct Vector
{
    public float direction;
    public int magnitude;
}
Vector[] vectors = new Vector [1000];
這將把1000個Vector分配在一塊空間上,這比我們把Vector聲明為類並使用for迴圈去執行個體化1000個獨立的Vector來得有效率得多。【譯註:因懷疑原文有誤,此處故意漏譯一句,但不應影響你對這節內容的理解】:
int[] ints = new ints[1000];//【譯註:此處代碼有誤,應為int[] ints = new int[1000];】
C#完全允許你擴充內建在語言中的基本類型集。實際上,C#所有的基本類型都以結構方式實現的。int型只不過是System.Int32結構的別名,long型不過是System.Int64結構的別名等等。這些基本類型當然可被編譯器特別處理,但是語言本身並無區別【譯註:意思是語言自身對處理所有類型提供了一致的方法】。在下一節中,我們可看到C#是如何做到這一點的。
9.類型一致
     大多數語言都有基本類型(int、long等等)。進階類型最終是由基本類型構成的。能以同樣的方式處理基本類型和進階類型通常來說是有用處的。例如,如果集合可以象包容sting那樣包容int是有用的。為此,Smalltalk通過犧牲些許效率象處理string或Form一樣來處理int和long。Java試圖避免這個效率損失,它象C和C++那樣處理基本類型,但又為每一個基本類型提供了相應的封裝類—int封裝為Integer,double封裝為Double。C++模板參數可接受任何類型,只要該類型提供了模板定義的操作的實現。
【譯註:在Java中,你可以這麼寫:
int i = 1;
      double d = 1.1;
      Integer iObj = new Integer(1);
Double dObj = new Double(1.1);
以下寫法是錯誤的:
int I = new int(1);
Integer iObj = 1;

C#對該問題提供了一個不同的解決方案。在上一節裡,我介紹了C#中的結構,指出基本類型不過是結構的一個別名而已。既然結構擁有所有物件類型擁有的方法,那代碼就可以這麼寫:
int i = 5;
System.Console.WriteLine (i.ToString());
如果我們想象使用一個對象那樣使用一個結構,C#將為你裝箱該結構為對象,當你再次需要使用結構時,可以通過拆箱實現:
Stack stack = new Stack ();
stack.Push (i); // 裝箱
int j = (int) stack.Pop(); //拆箱
拆箱不僅是類型轉換的需要,它也是一個無縫處理結構和類之間關係的方式。你要清楚裝箱是做了建立封裝類的工作,儘管CLR可以為被裝箱的對象提供附加的最佳化。
【譯註:可以這麼認為,在C#中,對於任何值(結構)類型,都存在如下的封裝類:
class T_Box //T代表任何實值型別
{
    T Value;
    T_Box(T t){Value = t;}
}
當裝箱時,比如:
int n = 1;
object box = n;
概念上相當於:
int n = 1;
object box = new int_Box(i);
當拆箱時,比如:
object box = 1;
int n = (int)box;
概念上相當於:
object box = new int_Box(1);
int n = ((int_Box)box).Value;】
【作者註:C#的設計者在設計過程中應該考慮過模板。我懷疑未採用模板有兩個原因:第一個是混亂,模板可能很難和物件導向的特性融合在一起,它為程式員的帶來了太多的(混亂)設計可能性,而且它很難和反射一起工作;第二點是,如果.NET庫(例如集合類)沒有使用模板的話,模板將不會太有用。不過,果真.NET類使用了它們,那將有20多種使用.NET類的語言不得不也要能和模板一起工作,這在技術上是非常難以實現的。
注意到模板(泛型)已經被Java社團考慮納入Java語言規範之中是一件有意思的事。或許每個公司都會各唱各的調—Sun說“.NET患了最小公分母綜合症”,而微軟則說“Java不支援多語言”。
(8月10日致歉)看了一個對Anders Hejlsberg的專訪後(http://windows.oreilly.com/news/hejlsberg_0800.html),感覺似乎模板已浮出地平線,但第一版沒有,正因我們上面提到的種種困難。看到IL規範是如此寫法使得IL碼可以展現模板(用一個非破壞的方式以讓反射可以很好的工作)而位元組碼則不可以是一件很有趣的事。在此,我還給出了一個關於Java社團考慮要加入泛型的連結:http://jcp.org/jsr/detail/014.jsp 】
【譯註:此處是上文提到的對Anders Hejlsberg採訪的中文版連結:http://www.csdn.net/develop/article/11/11580.shtm。另外,如欲瞭解更多關於泛型程式設計知識,請參見此處連結:http://www.csdn.net/develop/article/11/11440.shtm】

相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。