我最近遇到过这种情况，到目前为止，我一直在高兴地重写等式运算符（ == ）和/或等于方法，以查看是否有两个引用类型实际上包含相同的数据（即两个看起来相同的不同实例）。
我一直在使用它，因为我已经进行了更多的自动化测试（比较参考/预期数据与返回的数据）。
在查看coding standards guidelines in MSDN的某些内容时，我遇到了article建议反对它。现在我理解为什么文章说这个（因为它们不是同一个实例）但它没有回答这个问题：
非常感谢^ _ ^
看起来我错误地阅读了一些文档（这是漫长的一天）并且覆盖Equals可能是最佳选择..
如果您正在实施参考 类型，你应该考虑覆盖 引用类型上的Equals方法 如果您的类型看起来像基本类型 如Point，String，BigNumber， 等等。大多数参考类型应该 不要超载相等运算符， 甚至如果他们覆盖等于。然而， 如果您正在实施参考 打算有价值的类型 语义，例如复数 类型，你应该重写相等 操作
答案 0 :(得分：26)
正确，高效地实现.NET中的相等性和无代码重复很难实现。具体来说，对于具有值语义的引用类型（即immutable types that treat equvialence as equality），您应该实现the System.IEquatable<T> interface，并且应该实现所有不同的操作（Equals，GetHashCode和{{1 }，==）。
作为一个例子，这是一个实现值相等的类：
!=上述代码中唯一可移动的部分是粗体部分：class Point : IEquatable<Point> {
public int X { get; }
public int Y { get; }
public Point(int x = 0, int y = 0) { X = x; Y = y; }
public bool Equals(Point other) {
if (other is null) return false;
return X.Equals(other.X) && Y.Equals(other.Y);
}
public override bool Equals(object obj) => Equals(obj as Point);
public static bool operator ==(Point lhs, Point rhs) => object.Equals(lhs, rhs);
public static bool operator !=(Point lhs, Point rhs) => ! (lhs == rhs);
public override int GetHashCode() => X.GetHashCode() ^ Y.GetHashCode();
}中的第二行和Equals(Point other)方法。其他代码应保持不变。
对于不表示不可变值的引用类，请不要实现运算符GetHashCode()和==。相反，使用它们的默认含义，即比较对象标识。
代码故意等同于派生类类型的偶数对象。通常，这可能不合适，因为基类和派生类之间的相等性没有明确定义。不幸的是，.NET和编码指南在这里并不十分清楚。 Resharper创建的代码（已发布in another answer）在这种情况下容易受到不良行为的影响，因为!=和Equals(object x) 将以不同方式处理此案例。
要更改此行为，必须在上面的强类型Equals(SecurableResourcePermission x)方法中插入其他类型检查：
Equals答案 1 :(得分：22)
看起来你正在使用C＃编码，它有一个你的类应该实现的Equals方法，如果你想使用其他指标来比较两个对象而不是“这两个指针（因为对象句柄就是这样，指针）到同一个内存地址？“。
我从here获取了一些示例代码：
class TwoDPoint : System.Object
{
public readonly int x, y;
public TwoDPoint(int x, int y) //constructor
{
this.x = x;
this.y = y;
}
public override bool Equals(System.Object obj)
{
// If parameter is null return false.
if (obj == null)
{
return false;
}
// If parameter cannot be cast to Point return false.
TwoDPoint p = obj as TwoDPoint;
if ((System.Object)p == null)
{
return false;
}
// Return true if the fields match:
return (x == p.x) && (y == p.y);
}
public bool Equals(TwoDPoint p)
{
// If parameter is null return false:
if ((object)p == null)
{
return false;
}
// Return true if the fields match:
return (x == p.x) && (y == p.y);
}
public override int GetHashCode()
{
return x ^ y;
}
}
Java具有非常相似的机制。 equals（）方法是 Object 类的一部分，如果你想要这种类型的功能，你的类会重载它。
重载'=='的原因对于对象来说可能是一个坏主意，通常，您仍然希望能够执行“这些是相同的指针”比较。这些通常依赖于，例如，将元素插入到不允许重复的列表中，如果此运算符以非标准方式过载，则某些框架内容可能无效。
答案 2 :(得分：16)
答案 3 :(得分：3)
该文章建议不要覆盖等于运算符（对于引用类型），而不是覆盖重写等号。如果相等检查不仅仅意味着检查，那么您应该在对象（引用或值）中覆盖Equals。如果需要接口，还可以实现IEquatable（由泛型集合使用）。但是，如果确实实现了IEquatable，则还应该重写equals，因为IEquatable备注部分指出：
如果实现IEquatable＆lt; T＆gt;，则还应覆盖Object.Equals（Object）和GetHashCode的基类实现，以使它们的行为与IEquatable＆lt; T＆gt; .Equals方法的行为一致。如果您重写了Object.Equals（Object），则在调用类上的静态Equals（System.Object，System.Object）方法时也会调用重写的实现。这确保了Equals方法的所有调用都返回一致的结果。
关于是否应该实现Equals和/或相等运算符：
来自Implementing the Equals Method
大多数引用类型不应重载相等运算符，即使它们重写等于。
来自Guidelines for Implementing Equals and the Equality Operator (==)
每当实现相等运算符（==）时重写Equals方法，并使它们执行相同的操作。
这只表示每当实现相等运算符时都需要重写Equals。 不表示在重写Equals时需要覆盖相等运算符。
答案 4 :(得分：2)
对于将产生特定比较的复杂对象，然后实现IComparable并在Compare方法中定义比较是一个很好的实现。
例如，我们有“Vehicle”对象，唯一的区别可能是注册号，我们使用它进行比较，以确保测试中返回的预期值是我们想要的值。
答案 5 :(得分：1)
我倾向于使用Resharper自动制作的东西。例如，它为我的一个引用类型自动处理：
public override bool Equals(object obj)
{
if (ReferenceEquals(null, obj)) return false;
if (ReferenceEquals(this, obj)) return true;
return obj.GetType() == typeof(SecurableResourcePermission) && Equals((SecurableResourcePermission)obj);
}
public bool Equals(SecurableResourcePermission obj)
{
if (ReferenceEquals(null, obj)) return false;
if (ReferenceEquals(this, obj)) return true;
return obj.ResourceUid == ResourceUid && Equals(obj.ActionCode, ActionCode) && Equals(obj.AllowDeny, AllowDeny);
}
public override int GetHashCode()
{
unchecked
{
int result = (int)ResourceUid;
result = (result * 397) ^ (ActionCode != null ? ActionCode.GetHashCode() : 0);
result = (result * 397) ^ AllowDeny.GetHashCode();
return result;
}
}
如果您要覆盖==并仍然进行参考检查，您仍然可以使用Object.ReferenceEquals。
答案 6 :(得分：1)
Microsoft似乎已经改变了他们的调整，或者至少存在关于不重载相等运算符的冲突信息。根据这个标题为“如何：为类型定义价值平等”的Microsoft article：
＆＃34;即使类没有超载它们，==和！=运算符也可以与类一起使用。但是，默认行为是执行引用相等性检查。在类中，如果重载Equals方法，则应该重载==和！=运算符，但这不是必需的。＆＃34;
Eric Lippert在answer的问题中提到了Minimal code for equality in C#的一个问题 - 他说：
＆＃34;您遇到的危险是您为自己定义的==运算符默认情况下引用相等性。您可以很容易地在一个重载的Equals方法确实值相等并且==确实引用相等的情况下结束，然后您不小心在值相等的非引用相等的事物上使用引用相等。这是一种容易出错的做法，人工代码审查很难发现。
几年前，我使用静态分析算法来统计检测这种情况，我们发现在我们研究的所有代码库中，每百万行代码中有大约两个实例的缺陷率。当只考虑具有某些被覆盖的Equals的代码库时，缺陷率显然要高得多！
此外，考虑成本与风险。如果您已经拥有IComparable的实现，那么编写所有运算符都是微不足道的单行程序，它们不会有错误并且永远不会被更改。这是你写的最便宜的代码。如果在编写和测试十几种微小方法的固定成本与发现和修复难以看到的错误的无限成本之间做出选择，其中使用引用相等而不是值相等，我知道我会选择哪一个。 ＃34;
.NET Framework永远不会使用您编写的任何类型的==或！=。但是，如果其他人这样做会发生危险。因此，如果该类用于第三方，那么我将始终提供==和！=运算符。如果该类仅用于组内部使用，我仍然可能实现==和！=运算符。
如果实现了IComparable，我只会实现＆lt;，＆lt; =，＆gt;和＆gt; =运算符。只有当类型需要支持排序时才应该实现IComparable - 比如在排序或在SortedSet等有序通用容器中使用时。
如果集团或公司制定了一项政策，以便不实施==和！=运营商 - 那么我当然会遵循该政策。如果这样的策略到位，那么使用Q / A代码分析工具强制执行它是明智的，该工具在与引用类型一起使用时标记==和！=运算符的任何出现。
答案 7 :(得分：0)
我认为在.NET的设计中，获取像检查对象一样简单正确的东西是有点棘手的。
对于Struct
1）实施IEquatable<T>。它显着提高了性能。
2）由于您现在拥有自己的Equals，请覆盖GetHashCode，并与各种等式检查覆盖object.Equals一致。
3）重载==和!=运算符不需要虔诚地完成，因为如果你无意中将一个结构与一个结构等同于==或!=，编译器会发出警告，但这样做有利于与Equals方法保持一致。
public struct Entity : IEquatable<Entity>
{
public bool Equals(Entity other)
{
throw new NotImplementedException("Your equality check here...");
}
public override bool Equals(object obj)
{
if (obj == null || !(obj is Entity))
return false;
return Equals((Entity)obj);
}
public static bool operator ==(Entity e1, Entity e2)
{
return e1.Equals(e2);
}
public static bool operator !=(Entity e1, Entity e2)
{
return !(e1 == e2);
}
public override int GetHashCode()
{
throw new NotImplementedException("Your lightweight hashing algorithm, consistent with Equals method, here...");
}
}
适用于课程
来自MS：
大多数引用类型不应重载相等运算符，即使它们重写等于。
对我来说==感觉就像价值平等，更像是Equals方法的语法糖。写a == b比写a.Equals(b)更直观。我们很少需要检查参考平等。在处理物理对象的逻辑表示的抽象级别中，这不是我们需要检查的。我认为为==和Equals设置不同的语义实际上可能令人困惑。我认为它应该是==用于值相等，而Equals用于引用（或更好的名称，如IsSameAs）首先是平等。 我很想在这里不认真对待MS指南，不仅因为这对我来说不自然，而且因为超载==没有造成任何重大伤害。这不是没有重写可以咬回的非通用Equals或GetHashCode，因为框架不会在任何地方使用==，但仅限于我们自己使用它。我从没有重载==和!= 获得的唯一真正好处将是与我无法控制的整个框架的设计的一致性。这确实是一件大事，很遗憾我会坚持下去。
使用引用语义（可变对象）
1）覆盖Equals和GetHashCode。
2）实施IEquatable<T>不是必须的，但如果你有一个就很好。
public class Entity : IEquatable<Entity>
{
public bool Equals(Entity other)
{
if (ReferenceEquals(this, other))
return true;
if (ReferenceEquals(null, other))
return false;
//if your below implementation will involve objects of derived classes, then do a
//GetType == other.GetType comparison
throw new NotImplementedException("Your equality check here...");
}
public override bool Equals(object obj)
{
return Equals(obj as Entity);
}
public override int GetHashCode()
{
throw new NotImplementedException("Your lightweight hashing algorithm, consistent with Equals method, here...");
}
}
使用值语义（不可变对象）
这是棘手的部分。如果不加以照顾，很容易搞砸..
1）覆盖Equals和GetHashCode。
2）重载==和!=以匹配Equals。 确保它适用于空值。
2）实施IEquatable<T>不是必须的，但如果你有一个就很好。
public class Entity : IEquatable<Entity>
{
public bool Equals(Entity other)
{
if (ReferenceEquals(this, other))
return true;
if (ReferenceEquals(null, other))
return false;
//if your below implementation will involve objects of derived classes, then do a
//GetType == other.GetType comparison
throw new NotImplementedException("Your equality check here...");
}
public override bool Equals(object obj)
{
return Equals(obj as Entity);
}
public static bool operator ==(Entity e1, Entity e2)
{
if (ReferenceEquals(e1, null))
return ReferenceEquals(e2, null);
return e1.Equals(e2);
}
public static bool operator !=(Entity e1, Entity e2)
{
return !(e1 == e2);
}
public override int GetHashCode()
{
throw new NotImplementedException("Your lightweight hashing algorithm, consistent with Equals method, here...");
}
}
如果您的类可以继承，请特别注意它应该如何运行，在这种情况下，您必须确定基类对象是否可以等于派生类对象。理想情况下，如果没有派生类的对象用于相等性检查，那么基类实例可以等于派生类实例，在这种情况下，不需要检查泛型Type中的Equals相等性基类的。
一般注意不要重复代码。我可以创建一个通用的抽象基类（IEqualizable<T>左右）作为模板，以便更容易重用，但遗憾的是在C＃中阻止我从其他类派生。
答案 8 :(得分：0)
以上所有答案均未考虑多态性，即使通过基本引用进行比较，通常您仍希望派生引用使用派生等于。请在此处查看问题/讨论/答案-Equality and polymorphism