C# - 为引用类型重定义相等性

一般状况下引用类型的相等性是不该该被重定义/重写的。

例如两个引用类型的变量 x 和 y，若是这样写：if(x == y) {...}，那么你们都明白，这个比较的是引用的相等性。

可是有少数状况下，也能够为引用类型重写相等性。

例如这个类：

这个类里面只有两个string类型的属性和字段，那么对它的相等性来讲，更合理的是去比较值，而不是引用。

 

还有一种状况，就是表示数学的引用类型。

例若有一个类表示矩阵 Matrix，那么这样写 if(matrix1 == matrix2) {...} 更适合表示它们两个的值相等。

 

上述的这两个例子其实也不是十分的必要。因此想为引用类型重写相等性的时候仍是应该先想好，重写后是否可以更加的直观，使理解便得更简单了。

实际上若是想比较两个应用类型里面的值是否相等，你没必要非得去重写那些相等性的方法，你能够经过实现IEqualityComparer<T>接口来写一个单独的相等性比较器。可是这样的话不能使用==操做符，须要这样写：if(eqComparer.Equals(x, y)) {...}

 

为引用类型重写相等性

一个类：

首先重写object.Equals()方法：

这个逻辑比较简单，就是判断null，引用和类型，而后再判断各个属性（字段）的值是否相等。

 

而后还须要重写object.GetHashCode()方法:

这个采用了Resharper生成的方法，之前说过，就再也不介绍了。

 

最佳实践还要求重写C#的==操做符：

固然配套的!=也必须重写。

 

在以前重写值类型相等性的文章里，我还为值类型实现了IEquatable<T>接口，而对于引用类型来讲，就没有必要去实现该接口了，能够把相等性判断逻辑放在object.Equals()方法里。

 

派生类

这是上面Citizen类的一个子类：

 

下面我重写object.Equals() 方法：

大部分逻辑都在base.Equals()方法里了，首先若是父类的Equals()方法返回false，那么下面也就不用作啥了。可是若是父类Equals()认为这两个实例是相等的，这就意味着父类里全部的相等性检查都经过了，而后咱们仍然须要检查派生类里面的独有字段（属性），而这个例子里只有一个字段（属性）。

而后别忘了实现GetHashCode()方法：

（resharper生成的代码）

这个方法里使用了父类的GetHashCode()方法，把它按位异或IdCard的GetHashCode()的结果。

 

而后实现==和!=操做符：

好，如今咱们来测试一下：

其结果以下：

这个结果还都是对值进行比较的，符合预期。

 

而后你可能觉得这样实现没有问题了。。。。

陷阱 

如今我在Citizen这个父类里修改一下==的实现，我想让它更有效率：

而后我再执行和上面一样的测试代码，其结果输入是：

 

😱，全都相等了。。。。确定不对。。

 

那在父类里的==方法设一下断点看看：

这里面x和y其实都是BeijingCitizen的实例，可是如今所处的位置是其父类Citizen的==方法里，因此相等性检查会在这里发生，因此这个相等性检查只会检查父类里面的字段，Citizen这个类没法知道其它继承于它的类型，因此这里也没法比较派生类独有的字段，在这里就是IdCard。而全部这些实例的不一样值就去别再IdCard这个派生类的字段上面了，因此全部检查的结果都是相等的，由于只比较了父类的那两个字段。

为何会调用Citizen父类的==方法呢？由于该方法是静态的，也就不是virtual的。而个人测试代码：

其参数类型是父类Citizen，因此a==b这句话会在编译时就决定采起哪一个版本的==实现，而编译器在这个方法里会看到a和b的类型都是Citizen，因此它会调用Citizen版本的==实现。

 

因此这确实是一个陷阱。

 

可是为何原来的写法就没有问题呢？

原来的写法里，在Citizen这个父类里，==的实现调用了 object的静态Equals()方法，而在这个静态Equals方法里：

又调用了object的virtual Equals()方法，而若是实际类型是BeijingCitizen的话，那么就会调用override的Equals()方法，咱们单独看这个比较：

在BeijingCitizen里设一个断点：

能够看到会击中该断点。也能够看一下CallStack：

 

如今再次运行全部测试，其结果：

就是正确的了。

 

因此说，相等性检查的逻辑须要放在virtual的方法里。

 

若是再往上一级，把参数都变成object类型：

输出结果是：

这是由于==的实现不是virtual的，在object类型上使用==就是判断引用的相等性。而你也没法在重载操做符来防止上述事情的发生，由于这段代码永远不会调用到你的操做符重载方法。

 

那么结论就是，在操做符重载方法里调用vitual的方法，就能够应付继承相关的相等性判断，可是至少也得输入你定义的父类的类型（Citizen），好让你定义的操做符重载方法能够被最早调用。若是要知足继承、相等性这两方面的要求，那么就须要牺牲类型安全:

因此==操做符重载，能够看做一种方便的语法糖法，同时也把类型不安全的Equals()方法包装了起来。

 

为何不实现IEquatable<T> 

若是我在Citizen类里面实现了该接口：

那么方法里的调用也仍是调用virtual的Equals()，不然的话仍是同样的bug。那么这样看的话，实现该接口几乎没有什么新鲜的做用，虽说该方法能够作到必定程度的类型安全，可是性能上，比直接调用object.Equals()更慢了。

因此针对引用类型，不建议实现IEquatable<T>接口。

 

非得实现的话建议sealed

例如：

这样的话，咱们就能够把判断相等的逻辑写在该方法里了，由于这个类是sealed，因此能传递到这个方法里的变量必定是该类型的，没有继承的存在，咱们就能够同时拥有类型安全和相等性了。

 

为sealed的class实现IEquatable<T>接口确定是可行的，可是否值得呢？

优势：能获得微小的性能提高，string就是个例子。

缺点：class自己就更复杂了，你须要记住3种实现相等性判断的方式。。。

综上我的建议是针对引用类型不去实现IEquatable<T>接口。