equals（…）和equalsIgnoreCase（…）

为什么我们将equals()和equalsIgnoreCase()作为两个不同的方法，当equals()可以使用特殊的ignoreCase参数重载以提供equalsIgnoreCase()function时？

Answer 1

方法equals()inheritance自Object ，因此不应更改其签名。 equals()通常可以在不实际知道对象的具体类的情况下使用，例如在迭代对象集合时（特别是在Java 5generics之前）。 那么你甚至不会看到其他equals()而不首先将你的对象向下转换为String 。

这是来自Java创建者的设计选择，使得使用equals()的习惯用法对所有对象使用完全相同的方式。

此外，IMO

 if (string1.equalsIgnoreCase(string2)) ... 

更具可读性，因此不易出错

 if (string1.equals(string2, true)) ... 

当然，在你自己的类中，你可以自由地添加一个带有不同签名的equals() （在标准的equals()之上）。

Answer 2

equalIgnoreCase()用于忽略String的Case敏感。 但是equals()只返回true ，而string是相同的

当然，

 String value="java"; if(value.equals("JAva") { System.out.println("Return True"); } else { System.out.println("Return False"); } 

Ans：返回False

但另一个是，

 if(value.equalIgnoreCase("JAva") { System.out.println("Return True"); } else { System.out.println("Return False"); } 

Ans：返回True

Answer 3

绝对有可能做你所建议的但是语言设计者选择了另一种方式，因此我们有equalsIgnoreCase(otherString)而不是说equals(otherString, StringConstants.IGNORE_CASE)或equals(otherString, true) 。

Answer 4

因为equals()方法是从Objectinheritance的。

如果他们按照你的建议做了那么我们会有这样的事情：

 public final class String { public boolean equals () { ... } public boolean equals (boolean ignoreCase) { ... } } 

如果没有阅读文档，就无法理解equals() （没有参数）的方法。

Answer 5

使用附加参数覆盖方法时的主要测试是，我希望任何方法覆盖与覆盖它的方法完全相同。 从Object派生的Equals（）有一个必须遵循的契约。 两个相等的对象（）应该具有相同的哈希码。 我不认为两个不区分大小写的对象应该具有相同的哈希码，所以我认为在这里覆盖相等是错误的。

Answer 6

  // Demonstrate equals() and equalsIgnoreCase(). class equalsDemo { public static void main(String args[]) { String s1 = "Hello"; String s2 = "Hello"; String s3 = "Good-bye"; String s4 = "HELLO"; System.out.println(s1 + " equals " + s2 + " -> " + s1.equals(s2)); System.out.println(s1 + " equals " + s3 + " -> " + s1.equals(s3)); System.out.println(s1 + " equals " + s4 + " -> " + s1.equals(s4)); System.out.println(s1 + " equalsIgnoreCase " + s4 + " -> " + s1.equalsIgnoreCase(s4)); } } 

程序的输出如下所示：

 Hello equals Hello -> true Hello equals Good-bye -> false Hello equals HELLO -> false Hello equalsIgnoreCase HELLO -> true 

Answer 7

我认为他们只是选择了其中一种替代品。 .NET选择了另一个。 StringComparison.InvariantCultureIgnoreCase等

肯定你所建议的和[甚至更好的] .NET实现对不同的文化等更灵活。事实上，我甚至不知道他们在这种忽略情况下使用什么文化。 我猜当前的文化。