IEquable和OvingObject.Equals()之间有什么区别?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (16)

我希望我的Food能够测试什么时候它等于另一个实例Food。我将在后面的列表中使用它,并且我想使用它的List.Contains()方法。我应该实施IEquatable<Food>还是仅仅覆盖Object.Equals()?来自MSDN:

此方法通过使用默认的相等比较器来确定相等性,如T(对象列表中值的类型)的对象实现的IEquatable.Equals方法所定义的。

所以我的下一个问题是:.NET框架的哪些函数/类使用Object.Equals()?我应该首先使用它吗?

提问于
用户回答回答于

主要原因是性能。当泛型介绍.NET 2.0中,他们能够增加一堆整齐班如List<T>Dictionary<K,V>HashSet<T>,等这些结构大量使用GetHashCodeEquals。但对于价值类型,这需要拳击。IEquatable<T>让一个结构实现一个强类型的Equals方法,因此不需要装箱。因此,在使用泛型集合的值类型时性能会好得多。

引用类型不会受益太多,但IEquatable<T>实现确实可以让您避免投射,System.Object如果频繁调用该投射会产生变化。

用户回答回答于

如果实现IEquatable(T),则还应该重写Object.Equals(Object)和GetHashCode的基类实现,以便它们的行为与IEquatable(T).Equals方法的行为一致。如果您重写Object.Equals(Object),则在调用您的类上的静态Equals(System.Object,System.Object)方法时,也会调用您的重写实现。这确保Equals方法的所有调用返回一致的结果。

因此,似乎两者之间没有真正的功能差异,除非可以根据类如何使用来调用。从性能角度来看,它更好地使用通用版本,因为不存在与其相关的装箱/拆箱处罚。

从逻辑的角度来看,实现接口也更好。重写对象并不能真正告诉任何人你的类实际上是可以相等的。重写可能只是一个无所事事的类或浅层实现。明确地使用接口说:“嘿,这个东西适用于平等检查!” 这只是更好的设计。

扫码关注云+社区