为什么要为值类型重定义相等性

原因主要有以下几点：

• 值类型默认无法使用 == 操作符，除非对它进行重写
• 再就是性能原因，因为值类型默认的相等性比较会使用装箱和反射，所以性能很差
• 根据业务需求，其实际相等性的意义和默认的比较结果可能会不同，但是这种情况可能不较少

所以建议是：所有供外部使用的struct都实现相等性。

 

实现步骤

• 重写object.Equals()方法
• 实现IEquatable<T>.Equals()接口方法
• 重写 == 和 != 操作符
• 重写object.GetHashCode()

具体来说：

重写object.Equals()方法，是避免了反射，因为System.ValueType里面对object.Equals()方法的重写实现如下：

这里用到了反射。

而实现IEquatable<T>.Equals()接口方法，可以避免装箱，并且保证类型安全。

而实现==和!=，也就允许值类型使用该操作符了，写起来更方便直观，易于理解。而且这两个操作符必须一同实现。

而重写object.GetHashCode()，则是一个最佳实践。

 

所有为值类型重定义相等性，一共分4步，每步都是必须的。

 

实现

先看实例struct：

有构造函数，涉及到一个enum，并重写了ToString()方法。

 

实现IEquatable<T>接口

首先来实现IEquatable<T>接口。

（如果你使用resharper或者Rider，那么实现该接口的时候它会自动把object的Equals和GetHashCode方法都重写了，并且自动完成了有意义的代码）

这里面我对三个属性进行了比较，使用了==操作符。其中==对于string来说就是比较值，而enum其实就是int，DateTime也是值类型，并且已经实现了相等性判断的功能。

 

重写object.Equals()方法

这个代码是resharper生成的。

代码很简单，首先检查是否为null，然后检查这个object是不是一个Person，这里使用了 is 操作符，并把它转型为Person，赋给了一个叫做other的变量。最后调用的这个Equals()方法，是我们上面写的那个强类型的方法，因为other变量的类型是Person。

但是这个方法仍然涉及到装箱操作，所以还是IEquatable<T>的实现方法更快一些。

 

如果只重写了object.Equals()方法，而没有重写GetHasCode()方法，那么resharper会有提示：

 

实现 == 和 != 操作符

 

这个很简单，直接调用强类型的Equals()方法即可，而且由于Person是值类型，所以不用检查null，值类型不会为null。

 

如果只实现了其中一个操作符，那么会报错的。

 

实现object.GetHashCode()

GetHashCode()这个方法会返回一个32位的哈希码，它代表着对象内容的哈希值。

而类型里拥有GetHashCode()方法（返回Hash）的真正目的是，允许该类型在内部使用HashTable的集合中可以作为Key，因为HashTable需要这些哈希码。例如Dictionary<TK, TV>。

为了让HashTable可以正确的工作，Hash码有一个要求：如果两个实例被认为是相等的，那么它们必须返回相同的hash码。如果没有实现这个要求，那么你可能会发现这个类型作为Dictionary的Key的时候，会有一些意想不到的结果。

所以如果重写了object.Equals()方法，那么就得重写object.GetHashCode()方法。

 

看一下resharper自动实现的代码：

这里使用了unchecked，防止抛出溢出异常。

Name是引用类型，可能为null，所以判断一下。

然后其它两个int和DateTime类型，微软都做好了其GetHashCode()的实现。

这里对它们进行异或操作。之所以使用397这个数，可能因为397是一个足够大的质数，可以导致溢出，并混淆各位，之所以使用质数，是因为用质数相乘会得到比用其他任意数相乘更均匀的结果。

 

检验

结果如预期，OK。

 

总结

在这几个动作里，实际的逻辑写在了IEquatable<T>.Equals()方法里，object.Equals()就是检查类型然后调用IEquatable<T>.Equals()，== 和 != 操作符也是调用IEquatable<T>.Equals()，而GetHashCode()则使用了按位异或。

 

最后再重复一次，为值类型定义相等性一定要实现上述4各步骤的5个方法。