blocks|key|3047016|text|主要原因是性能。当泛型在.NET+2.0中引入时，他们能够添加一堆整洁的类，如List<T>、Dictionary<K,V>、HashSet<T>等。这些结构大量使用了GetHashCode和Equals。但是对于值类型，这需要装箱。IEquatable<T>允许结构实现强类型的Equals方法，因此不需要装箱。因此，在泛型集合中使用值类型时，性能要好得多。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3047017|引用类型受益不大，但IEquatable<T>实现确实让您避免了System.Object的强制转换，如果频繁调用，这可能会有所不同。|3047018|但是，正如在Jared+Parson's+blog中所指出的，您的必须仍然实现标准的Object.Equals和Object.GetHashcode覆盖。|BOLD|3047019|entityMap|0|LINK|mutability|MUTABLE|url|https://blog.paranoidcoding.com/2009/01/15/if-you-implement-iequatable-t-you-still-must-override-object-s-equals-and-gethashcode.html^0|13|7|1B|F|1R|A|2C|B|2O|6|39|D|3W|6|0|A|D|W|D|0|X|2|16|D|1K|I|6|J|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@$9|T|A|U|B|C]|$9|V|A|W|B|C]|$9|X|A|Y|B|C]|$9|Z|A|10|B|C]|$9|11|A|12|B|C]|$9|13|A|14|B|C]|$9|15|A|16|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|17|8|@$9|18|A|19|B|C]|$9|1A|A|1B|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1C|8|@$9|1D|A|1E|B|J]|$9|1F|A|1G|B|C]|$9|1H|A|1I|B|C]]|D|@$9|1J|A|1K|1|1L]]|E|$]]|$1|K|3|-4|5|6|7|1M|8|@]|D|@]|E|$]]]|L|$M|$5|N|O|P|E|$Q|R]]]]

The main reason is performance. When generics were introduced in .NET 2.0 they were able to add a bunch of neat classes such as <code>List&lt;T&gt;</code>, <code>Dictionary&lt;K,V&gt;</code>, <code>HashSet&lt;T&gt;</code>, etc. These structures make heavy use of <code>GetHashCode</code> and <code>Equals</code>. But for value types this required boxing. <code>IEquatable&lt;T&gt;</code> lets a structure implement a strongly typed <code>Equals</code> method so no boxing is required. Thus much better performance when using value types with generic collections.
Reference types don't benefit as much but the <code>IEquatable&lt;T&gt;</code> implementation does let you avoid a cast from <code>System.Object</code> which can make a difference if it's called frequently.
As noted on <a href="https://blog.paranoidcoding.com/2009/01/15/if-you-implement-iequatable-t-you-still-must-override-object-s-equals-and-gethashcode.html" rel="noreferrer">Jared Parson's blog</a> though, you must still implement the standard <code>Object.Equals</code> and <code>Object.GetHashcode</code> overrides.

blocks|key|3047047|text|根据MSDN的说法|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3047048|3047049|如果实现IEquatable<T>，还应重写Object.Equals(Object)和GetHashCode的基类实现，以便它们的行为与IEquatable<T>.Equals方法的行为一致。如果确实重写了Object.Equals(Object)，则还会在调用类上的静态Equals(System.Object,+++System.Object)方法时调用重写的实现。这确保了Equals方法的所有调用都返回一致的结果。|blockquote|style|CODE|3047050|3047051|3047052|因此，这两者之间似乎没有真正的函数差异，只是它们都可以根据类的使用方式来调用。从性能的角度来看，最好使用通用版本，因为没有与之相关的装箱/拆箱损失。|3047053|从逻辑的角度来看，实现接口也更好。重写对象并不能真正告诉任何人你的类实际上是可等同的。覆盖可能只是一个不做任何事情的类或一个浅层实现。显式地使用这个接口会说，“嘿，这个东西对于相等检查是有效的！”这只是更好的设计。|3047054|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/ms131187.aspx^0|2|4|0|0|0|4|D|M|L|18|B|1X|K|2W|L|3T|12|5A|6|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@$A|Y|B|Z|1|10]]|C|$]]|$1|D|3|-4|5|6|7|11|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|12|8|@$A|13|B|14|H|I]|$A|15|B|16|H|I]|$A|17|B|18|H|I]|$A|19|B|1A|H|I]|$A|1B|B|1C|H|I]|$A|1D|B|1E|H|I]|$A|1F|B|1G|H|I]]|9|@]|C|$]]|$1|J|3|-4|5|6|7|1H|8|@]|9|@]|C|$]]|$1|K|3|-4|5|6|7|1I|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|1J|8|@]|9|@]|C|$]]|$1|N|3|O|5|6|7|1K|8|@]|9|@]|C|$]]|$1|P|3|-4|5|6|7|1L|8|@]|9|@]|C|$]]]|Q|$R|$5|S|T|U|C|$V|W]]]]

According to the <a href="http://msdn.microsoft.com/en-us/library/ms131187.aspx" rel="noreferrer">MSDN</a>:

<blockquote>
 If you implement <code>IEquatable&lt;T&gt;</code>, you
 should also override the base class
 implementations of
 <code>Object.Equals(Object)</code> and <code>GetHashCode</code>
 so that their behavior is consistent
 with that of the <code>IEquatable&lt;T&gt;.Equals</code>
 method. If you do override
 <code>Object.Equals(Object)</code>, your overridden
 implementation is also called in calls
 to the static <code>Equals(System.Object,
 System.Object)</code> method on your class.
 This ensures that all invocations of
 the <code>Equals</code> method return consistent
 results.
</blockquote>

So it seems that there's no real functional difference between the two except that either could be called depending on how the class is used. From a performance standpoint, it's better to use the generic version because there's no boxing/unboxing penalty associated with it.

From a logical standpoint, it's also better to implement the interface. Overriding the object doesn't really tell anyone that your class is actually equatable. The override may just be a do nothing class or a shallow implementation. Using the interface explicitly says, "Hey, this thing is valid for equality checking!" It's just better design.

blocks|key|3260807|text|用一个实际的例子来扩展Josh所说的。%2B1+to+Josh+-我正要在我的答案中写同样的话。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3260808|public+abstract+class+EntityBase+:+IEquatable<EntityBase>
{
++++public+EntityBase()+{+}

++++#region+IEquatable<EntityBase>+Members

++++public+bool+Equals(EntityBase+other)
++++{
++++++++//Generic+implementation+of+equality+using+reflection+on+derived+class+instance.
++++++++return+true;
++++}

++++public+override+bool+Equals(object+obj)
++++{
++++++++return+this.Equals(obj+as+EntityBase);
++++}

++++#endregion
}

public+class+Author+:+EntityBase
{
++++public+Author()+{+}
}

public+class+Book+:+EntityBase
{
++++public+Book()+{+}
}|code-block|syntax|javascript|3260809|这样，我就有了可重用的Equals()方法，它可以为我所有的派生类开箱即用。|3260810|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

Extending what Josh said with a practical example. +1 to Josh - I was about to write the same in my answer.

<pre><code>public abstract class EntityBase : IEquatable&lt;EntityBase&gt;
{
 public EntityBase() { }

 #region IEquatable&lt;EntityBase&gt; Members

 public bool Equals(EntityBase other)
 {
 //Generic implementation of equality using reflection on derived class instance.
 return true;
 }

 public override bool Equals(object obj)
 {
 return this.Equals(obj as EntityBase);
 }

 #endregion
}

public class Author : EntityBase
{
 public Author() { }
}

public class Book : EntityBase
{
 public Book() { }
}
</code></pre>

This way, I have re-usable Equals() method that works out of the box for all my derived classes.

blocks|key|310061|text|如果我们调用object.Equals，它会强制对值类型进行昂贵的装箱。在对性能敏感的场景中，这是不可取的。解决方案是使用IEquatable<T>。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|310062|public+interface+IEquatable<T>
{
++bool+Equals+(T+other);
}|code-block|syntax|javascript|310063|IEquatable<T>背后的想法是，它提供与object.Equals相同的结果，但速度更快。constrain+where+T+:+IEquatable<T>必须与如下所示的泛型类型一起使用。|310064|public+class+Test<T>+where+T+:+IEquatable<T>
{
++public+bool+IsEqual+(T+a,+T+b)
++{
++++return+a.Equals+(b);+//+No+boxing+with+generic+T
++}
}|310065|否则，它将绑定到slower+object.Equals()。|310066|entityMap^0|6|D|1P|D|0|0|0|D|O|D|1N|N|0|0|8|M|0^^$0|@$1|2|3|4|5|6|7|S|8|@$9|T|A|U|B|C]|$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|X|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|Y|8|@$9|Z|A|10|B|C]|$9|11|A|12|B|C]|$9|13|A|14|B|C]]|D|@]|E|$]]|$1|M|3|N|5|H|7|15|8|@]|D|@]|E|$I|J]]|$1|O|3|P|5|6|7|16|8|@$9|17|A|18|B|C]]|D|@]|E|$]]|$1|Q|3|-4|5|6|7|19|8|@]|D|@]|E|$]]]|R|$]]

If we call <code>object.Equals</code>, it forces to expensive boxing on value types. This is undesirable in performance-sensitive scenarios. The solution is to use <code>IEquatable&lt;T&gt;</code>.

<pre><code>public interface IEquatable&lt;T&gt;
{
 bool Equals (T other);
}
</code></pre>

The idea behind <code>IEquatable&lt;T&gt;</code> is that it gives the same result as <code>object.Equals</code> but more quickly. The constrain <code>where T : IEquatable&lt;T&gt;</code> must be used with generic types like below.

<pre><code>public class Test&lt;T&gt; where T : IEquatable&lt;T&gt;
{
 public bool IsEqual (T a, T b)
 {
 return a.Equals (b); // No boxing with generic T
 }
}
</code></pre>

otherwise, it binds to <code>slower object.Equals()</code>.

I want my <code>Food</code> class to be able to test whenever it is equal to another instance of <code>Food</code>. I will later use it against a List, and I want to use its <code>List.Contains()</code> method. Should I implement <code>IEquatable&lt;Food&gt;</code> or just override <code>Object.Equals()</code>? From MSDN:

<blockquote>
 This method determines equality by
 using the default equality comparer,
 as defined by the object's
 implementation of the
 IEquatable.Equals method for T
 (the type of values in the list).
</blockquote>

So my next question is: which functions/classes of the .NET framework make use of <code>Object.Equals()</code>? Should I use it in the first place?

What's the difference between IEquatable and just overriding Object.Equals()?

我希望我的Food类能够在与Food的另一个实例相等的时候进行测试。稍后我将对List使用它，并且我想使用它的List.Contains()方法。我应该实现IEquatable<Food>还是直接覆盖Object.Equals()？来自MSDN：此方法通过使用默认的相等比较器来确定相等，该等式比较器由T(列表中的值的类...

问IEquatable和仅仅覆盖Object.Equals()有什么区别？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问IEquatable和仅仅覆盖Object.Equals()有什么区别？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问IEquatable和仅仅覆盖Object.Equals()有什么区别？
EN