你会重载Equals么?about how to override Equals

本文介绍了Equals方法的作用,默认的Object.Equals比较引用,ValueType.Equals比较数据结构。还阐述了重载Equals的要点,包括必须重载GetHashCode、处理null情形以及解决软件复用带来的问题,最后指出Equals对大项目很重要。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

首先你必须了解Equals方法的作用。

默认的Object.Equals方法是比较两个应用是否指向同一对象:

 class A
 {
  public int a;
 }

A a1 = new A ();

a1.a = 10;

A a2 = new A ();

a2.a = 10;

这时,a1.Equals (a2)为False。

默认的ValueType.Equals方法是比较两个struct对象数据结构是否相同:

 struct A
 {
  public int a;
 }

A a1 = new A ();

a1.a = 10;

A a2 = new A ();

a2.a = 10;

这时,a1.Equals (a2)为True。

很多情况下,默认的Equals已经够用。

但各种情况下,你需要重载Equals,那么请看清一下条款在写Equals。

1。重载Equals必须重载GetHashCode

这是一条编译器的rule。如果你重载了Equals不重载GetHashCode,编译器会发出警报。

GetHashCode需要返回一个Int32值,这个值得规律很简单:

      如果两个对象相同,那么对象返回的HashCode必须相同。

      如果两个对象返回的HashCode不相同,那么这两个对象必定不相同。

这样就使得Equals的效率提高很多。因为GetHashCode通常成本比Equals小得多。

打个比方,如果要比较两个collection的对象是否一样(不分顺序),那么就要逐一比对他们内部包含的对象。这是一个费时的比对过程。GetHashCode在这个时候就显得尤为重要。

  public override int GetHashCode ()
  {
   int n = 0;
   foreach (object inner in this)
    n ^= inner.GetHashCode ();
   return n;
  }

  public override bool Equals (object obj)
  {
   if (obj.GetHashCode () != this.GetHashCode ())
    return false;
   // TODO:以下具体实现就不写了
  }

以上的Equals碰到不相同的情况很快就能排除掉,直接就return false了,碰到HashCode相同,那么两个对象可能相同,但不能就依此return true了,还要具体分析。

2。Equals碰到null时的情形

一般人在重写Equals的时候并未考虑碰到null时的情形,一旦被比对对象或者比对对象中一个为null,运行时错误就会产生。

其实解决方法很简单,把a.Equals (b)写成Object.Equals (a, b)。

Object的静态方法Equals会帮你处理null的对象。

所以重载运算符==,!=时也就要用到静态的Equals:

  public static bool operator == (T t1, T t2)
  {
   return Object.Equals (t1, t2);
  }
  public static bool operator != (T t1, T t2)
  {
   reutrn !Object.Equals (t1, t2);
  }


3。Equals对软件复用带来的影响

先来看一个例子:

 class A
 {
  public int a;
  public override int GetHashCode ()
  {
   return a.GetHashCode ();
  }
  public override bool Equals (object obj)
  {
   if (obj.GetHashCode () != this.GetHashCode ())
    return false;
   if (obj is A && (obj as A).a == a)
    return true;
   return false;
  }
 }
 class B
 {
  public long b;
  public override int GetHashCode ()
  {
   return b.GetHashCode();
  }
  public override bool Equals (object obj)
  {
   if (obj.GetHashCode () != this.GetHashCode ())
    return false;
   if (obj is B && (obj as B).b == b)
    return true;
   if (obj is A && (obj as A).a == b)
    return true;
   return false;
  }
 }

 class Program
 {
  static void Main (string[] args)
  {
   A a1 = new A ();
   a1.a = 20;
   B b1 = new B ();
   b1.b = 20;
   Console.WriteLine (a1.Equals (b1));
   Console.WriteLine (b1.Equals (a1));
  }
 }

在这个例子中A只认得自己人,新来的类B不仅认得自己人,还认得以前就有的A。

然后就出现了不该有的一幕:a1.Equals (b1)返回False,而b1.Equals (a1)返回了True。

这可如何是好。系统应该听那个呢?

这就是软件添加新类后遇到的麻烦。你必须改动已有的类来让他认识新来的。但如果已有的类无法修改呢?

办法也是有的。那就是建立一个EqualManager:

public class TwoTypes
{
  Type t1, t2;
  public TwoTypes (Type t1, Type t2)
  {
    this.t1 = t1; this.t2 = t2;
  }
  public override int GetHashCode ()
  {
    reutrn t1.GetHashCode() ^ t2.GetHashCode(); // 不分顺序
  }
  public override bool Equals (object obj)
  {
    if (obj.GetHashCode() != this.GetHashCode())
        return false;
    if (obj is TwoTypes)
    {
       Type tt1 = (obj as TwoTypes).t1, tt2 = (obj as TwoTypes).t2;
       if (tt1 == t1 && tt2 == t2)
         return true;
       if (tt1 == t2 && tt2 == t1)
         return true;
    }
    return false;
  }
}
public class EqualManager : IComparer  // singleton
{
  Hashtable ht = new Hashtable ();
  private EqualManager ()
  {
  }
  public readonly EqualManager Instance = new EqualManager ();
  public int Compare (object o1, object o2)
  {
    TwoTypes tt = new TwoTypes (o1.GetType(), o2.GetType());
    if (ht.ComtainsKey (tt))
    {
      return (ht[tt] as IComparer).Compare (o1, o2);
    }
    else
      return false;
  }
  public void RegisterComparer (Type t1, Type t2, IComparer comp)
  {
    this.ht.Add (new TwoTypes (t1, t2), comp);
  }
}

看看代码就知道具体实现了,需要比对服务的类只要这样重写Equals:
public override bool Equals (object obj)
{
  return EqualManager.Instance.Compare (this, obj) == 0;
}
然后具体的实现就要依赖一个IComparer了。这样既实现了程序的可扩展性。

总结语:
Equals对于较小的项目确实无所谓,但对于较大的项目就显得重要了,毕竟这是底层的东西。幸好它比较简单,各位只要掌握以上三点,我想Equals应该不在话下了把。

只是无聊时写的无聊文章,如有不对的地方敬请更正。

<think>嗯,用户这次聚焦在Comparator接口的equals方法是否为抽象方法的问题上,看来ta对Java接口的抽象方法规则存在疑惑。之前我已经解释过compare方法是抽象方法,而equals方法比较特殊,需要更深入说明。用户可能正在学习Java函数式接口,或者在实际编码时发现实现Comparator接口只需重写compare方法,因此对equals方法的状态产生疑问。ta的困惑点在于:为什么接口声明了equals方法却不需要实现?这背后涉及Java语言设计的历史原因和对象模型的底层逻辑。从技术角度看,这个问题可以拆解成三层:第一层是Java语言规范:所有接口方法默认抽象,但Object类方法例外。Comparator的equals方法签名与Object.equals完全一致,根据JLS§9.4.3规定,这种重复声明不会产生额外的抽象方法[^1][^3]。第二层是虚拟机实现:当类实现接口时,如果接口方法与Object类方法签名相同,JVM会自动使用Object中的实现。这就解释了为什么我们实现Comparator时,即使不写equals方法也能通过编译——父类Object已经提供了默认实现[^4]。第三层是函数式接口的校验机制:@FunctionalInterface注解在编译期检查时,会智能忽略与Object方法签名重合的方法。这正是Comparator能通过验证的关键[^1][^3]。用户可能没意识到的是,这种设计解决了菱形继承问题。设想如果接口的equals方法和类父类的equals方法冲突,Java通过“类优先”原则避免了二义性。这个知识点虽然不在当前问题范围,但可以作为延伸内容储备。需要提醒用户的是,实践中若强行在Comparator实现类中重写equals方法,通常是为了实现特殊的缓存优化或基于身份的延迟加载等高级场景。但在测试中发现,这种情况下IDE会警告“重写最终方法”,因为Object.equals虽是实例方法但具有非final性,这个细节很有趣但可能超出用户当前需求。最后要强调下技术文档的严谨性。虽然StackOverflow上有讨论认为这种equals声明是接口设计的缺陷[^1],但根据Oracle官方文档,这属于深思熟虑的设计选择。在回复时需要引用JLS规范而不是论坛观点,才能确保回答的权威性。</think> 在Java中,`Comparator`接口的`equals`方法**不是抽象方法**。以下是关键分析(结合代码示例): ### 一、技术本质 1. **声明方式** 接口中声明的`equals`方法: ```java public interface Comparator<T> { boolean equals(Object obj); // 👉 看似抽象方法 } ``` **实际行为**:该方法签名与`Object.equals`完全一致,因此不增加新的抽象方法要求。 2. **JVM处理机制** 当类实现接口时,若接口方法与`Object`类方法签名相同: ```java public class MyComparator implements Comparator<String> { @Override public int compare(String a, String b) { ... } // ✅ 必须实现 // ❌ 无需重写 equals(),因为已继承 Object.equals } ``` ### 二、核心规范依据 | 规则来源 | 具体说明 | 结论 | |----------|----------|------| | Java语言规范(JLS
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值