等于(item, null) 或 item == null

Question

使用 static Object.Equals 检查 null 的代码是否更健壮比使用 == 运算符或常规 Object.Equals 的代码？后两者是否容易被覆盖，导致检查 null 无法按预期工作（例如，当比较值为 null 时返回 false）？

换句话说，是这样的：

if (Equals(item, null)) { /* Do Something */ }

比这样更健壮：

if (item == null) { /* Do Something */ }

我个人发现后者的语法更容易阅读。在编写处理作者控制之外的对象（例如库）的代码时是否应该避免这种情况？是否应该始终避免（检查 null 时）？这只是吹毛求疵吗？

Answer 1

这个问题没有简单的答案。在我看来，任何说总是使用其中之一的人都给了你不好的建议。

实际上，您可以调用多种不同的方法来比较对象实例。给定两个对象实例 a 和 b，您可以编写：

• Object.Equals(a,b)
• Object.ReferenceEquals(a, b)
• a.Equals(b)
• a == b

这些都可以做不同的事情！

Object.Equals(a,b) 将（默认情况下）对引用类型执行引用相等比较，对值类型执行按位比较。来自 MSDN 文档：

Equals 的默认实现
支持引用相等
引用类型和按位相等
对于值类型。引用相等
表示对象引用
比较指的是同一个对象。
按位相等意味着对象
被比较的具有相同的二进制
代表。

请注意，派生类型可能
重写 Equals 方法以
落实价值平等。价值
相等是指比较对象
具有相同但不同的值
二进制表示。

请注意上面的最后一段......我们稍后会讨论这个问题。

Object.ReferenceEquals(a,b) 仅执行引用相等性比较。如果传递的类型是装箱值类型，则结果始终为 false。

a.Equals(b) 调用 Object 的虚拟实例方法，a 的类型可以重写该方法做任何它想做的事。该调用是使用虚拟调度执行的，因此运行的代码取决于 a 的运行时类型。

a == b 调用 a 的**编译时类型*的静态重载运算符。如果该运算符的实现调用 a 或 b 上的实例方法，它还可能取决于参数的运行时类型。由于调度是基于表达式中的类型，因此以下可能会产生不同的结果：

Frog aFrog = new Frog();
Frog bFrog = new Frog();
Animal aAnimal = aFrog;
Animal bAnimal = bFrog;
// not necessarily equal...
bool areEqualFrogs = aFrog == bFrog;
bool areEqualAnimals = aAnimal = bAnimal;

因此，是的，使用operator ==检查空值存在漏洞。实际上，大多数类型不会重载== - 但永远无法保证。

实例方法 Equals() 在这里也好不到哪儿去。虽然默认实现执行引用/按位相等检查，但类型可能会覆盖 Equals() 成员方法，在这种情况下将调用此实现。用户提供的实现可以返回它想要的任何内容，即使与 null 进行比较也是如此。

但是您会问 Object.Equals() 的静态版本怎么样？这最终可以运行用户代码吗？好吧，事实证明答案是肯定的。 Object.Equals(a,b) 的实现扩展为以下内容：

((object)a == (object)b) || (a != null && b != null && a.Equals(b))

您可以自己尝试一下：

class Foo {
    public override bool Equals(object obj) { return true; }  }

var a = new Foo();
var b = new Foo();
Console.WriteLine( Object.Equals(a,b) );  // outputs "True!"

因此，语句可能为：Object.Equals( a,b) 在调用中的任何类型都不为 null 时运行用户代码。请注意，当任一参数为 null 时，Object.Equals(a,b) 不会调用 Equals() 的实例版本。

简而言之，您获得的比较行为类型可能会有很大差异，具体取决于您选择调用的方法。不过，这里有一个评论：微软没有正式记录 Object.Equals(a,b) 的内部行为。 如果您需要在不运行任何其他代码的情况下将引用与 null 进行比较的铁证，那么您需要 Object.ReferenceEquals()：

Object.ReferenceEquals(item, null);

此方法使意图极其清晰 - 您特别期望结果是两个引用的比较以确保引用相等。与使用诸如 Object.Equals(a,null) 之类的东西相比，这里的好处是稍后不太可能有人会说：

“嘿，这很尴尬，让我们替换它与：a.Equals(null)或a == null

这可能会有所不同，

让我们在这里注入一些实用主义。a == null。 - 在 .NET 类中，例如 String 和 Nullable 具有明确定义的比较语义，此外，它们是密封的 - 防止对其进行任何更改。以下是很常见的（也是正确的）：

string s = ...
if( s == null ) { ... }

没有必要（而且丑陋）编写：

if( ReferenceEquals(s,null) ) { ... }

因此在某些有限的情况下，使用 == 是安全且合适的。

Answer 2

if (Equals(item, null)) 并不比 if (item == null) 更强大，而且我发现启动起来更混乱。

Answer 3

当您想要测试 IDENTITY（内存中的同一位置）时：

ReferenceEquals(a, b)

处理空值。并且是不可重写的。 100%安全。

但请确保您确实想要身份测试。考虑以下几点：

ReferenceEquals(new String("abc"), new String("abc"))

返回 false。相比之下：

Object.Equals(new String("abc"), new String("abc"))

和

(new String("abc")) == (new String("abc"))

都返回 true。

如果您在这种情况下期望得到 true 答案，那么您需要的是 EQUALITY 测试，而不是 IDENTITY 测试。
请参阅下一部分。

---

当你想测试EQUALITY（相同内容）时：

• 如果编译器没有抱怨，请使用“a == b”。

• 被拒绝（如果变量 a 的类型没有定义“==”运算符），则使用“Object.Equals(a, b)”。

• 如果您处于已知a不为空的逻辑内部，那么您可以使用更具可读性的“a.Equals(b)< /代码>”。例如，“this.Equals(b)”是安全的。或者，如果“a”是在构造时初始化的字段，并且如果传入 null 作为要在该字段中使用的值，则构造函数会抛出异常。

现在，解决最初的问题：

问：这些是否容易在某些类中被覆盖，代码不能正确处理 null，从而导致异常？

答：是的。获得 100% 安全的 EQUALITY 测试的唯一方法是自己预先测试 null。

但你应该吗？错误就在那个（假设的未来坏类别）中，并且这将是一种简单的失败类型。易于调试和修复（由提供该类的人进行）。我怀疑这是一个经常发生的问题，或者当它发生时仍然持续很长时间的问题。

更详细的答：Object.Equals(a, b) 最有可能在编写糟糕的类时起作用。如果“a”为 null，则 Object 类将自行处理它，因此没有风险。如果“b”为空，则“a”的动态（运行时而非编译时）类型决定调用什么“Equals”方法。当“b”为空时，被调用的方法只需正确工作即可。除非被调用的方法写得非常糟糕，否则它所做的第一步是确定“b”是否是它理解的类型。

因此，Object.Equals(a, b) 是可读性/编码工作量和安全性之间的合理折衷。

Answer 4

框架指南建议您处理Equals 作为值相等（检查两个对象是否表示相同的信息，即比较属性），以及 == 作为引用相等，但不可变对象除外，对于这些对象，您可以使用也许应该重写 == 来实现值相等。

因此，假设准则适用于此，请选择语义上合理的那个。如果您正在处理不可变对象，并且您希望两种方法产生相同的结果，那么为了清楚起见，我将使用 == 。

Answer 5

关于“...编写将处理作者控制之外的对象的代码...”，我会指出 static Object.Equals 和 ==运算符是静态方法，因此不能虚拟/重写。调用哪个实现是在编译时根据静态类型确定的。换句话说，外部库无法为编译后的代码提供不同版本的例程。

Answer 6

这样做是因为两个空值无法进行比较

(a == null ? "NA" : a).equals(b == null ? "NA" : b)

Answer 7

当我试图比较本身可能为空的对象的唯一 ID 时，我最终来到这里。发现先估算缺失的数据，然后进行比较更容易。

Guid currentId = (Object1 == null) ? Guid.Empty : Object1.Id;
Guid newId = (Object2 == null) ? Guid.Empty : Object2.Id;
If (currentId == newId)
{
    //do happyface
}
else
{
   //do sadface
}