爲什麼要比較null時將對象轉換爲對象？

在Equals覆蓋中瀏覽MSDN文檔時，有一點引起了我的注意。爲什麼要比較null時將對象轉換爲對象？

論this specific page的例子，一些空的檢查是由，和做比較，當對象被澆鑄成System.Object的類型：

public override bool Equals(System.Object obj) 
{ 
    // If parameter is null return false. 
    if (obj == null) 
    { 
     return false; 
    } 

    // If parameter cannot be cast to Point return false. 
    TwoDPoint p = obj as TwoDPoint; 
    if ((System.Object)p == null) 
    { 
     return false; 
    } 

    // Return true if the fields match: 
    return (x == p.x) && (y == p.y); 
}

是否有使用該投一個具體的理由，或這只是在這個例子中被遺忘的一些「無用的」代碼？

來源

2010-08-04 Thibault Falise

類型可能會重載==運算符。轉換爲對象可確保使用原始定義。

來源

2010-08-04 15:26:16

因此使得exmaple代碼安全複製和粘貼。 – 2010-08-04 15:35:13

我相信鑄造到System.Object會繞過任何運算符重載TwoDPoint可能有。

來源

2010-08-04 15:25:36 Matt

這可能是==運算符超載的大樣本的一部分。在這種情況下，如果TwoDPoint.Equals（object）作爲==定義的一部分被調用，那麼使用obj == null可能會導致StackOverflow。

來源

2010-08-04 15:27:03

正如其他人所說，類型可能會覆蓋==運算符。因此，鑄造到Object相當於if (Object.ReferenceEquals(p, null)) { ... }。

來源

2010-08-04 15:29:49 Steven

+1使用ReferenceEquals對我來說比對對象更清晰 – Justin 2010-08-04 15:33:07

+1通過使用ReferenceEquals可以更清晰地顯示其意圖。 – 2010-08-04 16:41:47

它可能存在以避免與重載的==運算符混淆。想象一下，如果演員不存在，並且==運算符被超載。現在p == null行可能會綁定到運算符==。 operator ==的許多實現只是推遲重寫的Equals方法。這可能容易引起堆棧溢出的情況

public static bool operator==(TwoDPoint left, TwoDPoint right) { 
    return left.Equals(right); 
} 

public override bool Equals(System.Object obj) { 
    ... 
    TwoDPoint p = obj as TwoDPoint; 
    if (p == null) { // Stack overflow!!! 
     return false; 
    } 

    ... 
}

通過強制轉換爲Object筆者確保了簡單的參考支票null會發生（這是何意）。

來源

2010-08-04 15:32:59 JaredPar

爲什麼要比較null時將對象轉換爲對象？

回答

相關問題