MSDN代码示例:为什么在调用base之前进行强制转换.等于(对象)

本文关键字：转换 等于 对象 代码 为什么 base 调用 MSDN | 更新日期: 2023-09-27 18:21:39

在Microsoft MSDN Library关于Object.Equals方法（对象）的文章中(http://msdn.microsoft.com/en-us/library/bsc2ak47.aspx)给出了一个示例来演示如何重写Equals。它看起来像这样：

class Point
{
   ... // IEquatable<Point> is not implemented.
   public override bool Equals(Object obj) 
   {
      //Check for null and compare run-time types. 
      if ((obj == null) || ! this.GetType().Equals(obj.GetType())) {
         return false;
      }
      else { 
         Point p = (Point) obj; 
         return (x == p.x) && (y == p.y);
      }   
   }
}
sealed class Point3D: Point 
{
   int z;
   public override bool Equals(Object obj) 
   {
      Point3D pt3 = obj as Point3D;
      if (pt3 == null)
         return false;
      else 
         return base.Equals((Point)obj) && z == pt3.z; // Here!!!
   }
}

在随后的文件中，我注意到以下发言。

（如果它是Point3D对象，则将强制转换为Point对象并传递给Equals的基类实现。）

这里，return base.Equals((Point)obj)为什么要麻烦将obj转换为Point？

更新：

我想这可能只是一个拼写错误，当我查看.NET 4.0版本的文档时，它是一行代码：

return base.Equals(obj) && z == ((Point3D)obj).z

MSDN代码示例:为什么在调用base之前进行强制转换.等于(对象)

当需要相等性检查时，今天的建议是实现IEquatable<T>通用接口。其Equals(T)方法提供了类型安全性，并避免了值类型的装箱/取消装箱开销。

如果Point类实现了IEquatable<Point>接口，那么它将包含一个Equals(Point)方法重载，这比Equals(Object)调用更有效。一个合理的理由可能是，在实现所述接口的情况下，类型转换为Point是预先完成的。

class Point : IEquatable<Point>
{
   public Equals(Point other)
   {
       return other != null && this.x == other.x && this.y == other.y;
   }
   public override bool Equals(Object obj) 
   {
       return this.Equals(obj as Point);
   }
}

将obj强制转换为Point毫无意义（哈哈）。您是对的，Point.Equals方法也会将其强制转换为Point。它是多余的。

在Point类中，我们正在比较以下类型：

this.GetType().Equals(obj.GetType())

类型点不等于Point3D。

相关文章：