派生类

这是上面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>接口。

.NET社区新闻，深度好文，欢迎访问公众号文章汇总 http://www.csharpkit.com