深入equals方法对象相等比较

Java进阶:深入equals方法对象相等比较 
 
发布时间:2007.06.19 05:55     来源:赛迪网技术社区    作者:dxaw

equals方法的重要性毋须多言,只要你想比较的两个对象不愿是同一对象,你就应该实现equals方法,让对象用你认为相等的条件来进行比较.下面的内容只是API的规范,没有什么太高深的意义,但我之所以最先把它列在这儿,是因为这些规范在事实中并不是真正能保证得到实现.

1.对于任何引用类型, o.equals(o)==true 成立.

2.如果 o.equals(o1)==true 成立,那么o1.equals(o)==true也一定要成立.

3.如果 o.equals(o1)==true 成立且o.equals(o2)==true 成立,那么o1.equals(o2)==true 也成立.

4.如果第一次调用o.equals(o1)==true 成立再o和o1没有改变的情况下以后的任何次调用都成立.

5.o.equals(null)==true 任何时间都不成立.

以上几条规则并不是最完整的表述,详细的请参见API文档.对于Object类,它提供了一个最最严密的实现,那就是只有是同一对象是,equals方法才返回true,也就是人们常说的引用比较而不是值比较.这个实现严密得已经没有什么实际的意义,所以在具体子类(相对于Object来说)中,如果我们要进行对象的值比较,就必须实现自己的equals方法.

先来看一下以下这段程序:


public boolean equals(Object obj)
    {
        if (obj == null) return false;
        if (!(obj instanceof FieldPosition))
            return false;
        FieldPosition other = (FieldPosition) obj;
        if (attribute == null) {
            if (other.attribute != null) {
                return false;
            }
        }
        else if (!attribute.equals(other.attribute)) {
            return false;
        }
        return (beginIndex == other.beginIndex
            && endIndex == other.endIndex
            && field == other.field);
    }

这是JDK中java.text.FieldPosition的标准实现,似乎没有什么可说的.我信相大多数或绝大多数程序员认为,这是正确的合法的equals实现.毕竟它是JDK的API实现啊.还是让我们以事实来说话吧:


package debug;

import java.text.*;

public class Test {
  public static void main(String[] args) {
    FieldPosition fp = new FieldPosition(10);
    FieldPosition fp1 = new MyTest(10);
    System.out.println(fp.equals(fp1));
    System.out.println(fp1.equals(fp));
  }
}
class MyTest extends FieldPosition{
  int x = 10;
  public MyTest(int x){
    super(x);
    this.x = x;
  }
  public boolean equals(Object o){
    if(o==null) return false;
    if(!(o instanceof MyTest )) return false;
    return ((MyTest)o).x == this.x;
  }
}

运行一下看看会打印出什么:

System.out.println(fp.equals(fp1));打印true

System.out.println(fp1.equals(fp));打印flase

两个对象,出现了不对称的equals算法.问题出在哪里(脑筋急转弯:当然出在JDK实现的BUG)?我相信有太多的程序员(除了那些根本不知道实现equals方法的程序员外)在实现equals方法时都用过instanceof运行符来进行短路优化的,实事求是地说很长一段时间我也这么用过。太多的教程,文档都给了我们这样的误导。而有些稍有了解的程序员可能知道这样的优化可能有些不对但找不出问题的关键。另外一种极端是知道这个技术缺陷的骨灰级专家就提议不要这样应用。

我们知道,"通常"要对两个对象进行比较,那么它们"应该"是同一类型。所以首先利用instanceof运行符进行短路优化,如果被比较的对象不和当前对象是同一类型则不用比较返回false,但事实上,"子类是父类的一个实例",所以如果 子类 o instanceof 父类,始终返回true,这时肯定不会发生短路优化,下面的比较有可能出现多种情况,一种是不能造型成子类而抛出异常,另一种是父类的private 成员没有被子类继承而不能进行比较,还有就是形成上面这种不对称比较。可能会出现太多的情况。那么,是不是就不能用 instanceof运行符来进行优化?答案是否定的,JDK中仍然有很多实现是正确的,如果一个class是final的,明知它不可能有子类,为什么不用 instanceof来优化呢?为了维护SUN的开发小组的声誉,我不说明哪个类中,但有一个小组成员在用这个方法优化时在后加上了这样的注释:

if (this == obj) // quick check

return true;

if (!(obj instanceof XXXXClass)) // (1) same object?

return false;

可能是有些疑问,但不知道如何做(不知道为什么没有打电话给我......)那么对于非final类,如何进行类型的quick check呢?

if(obj.getClass() != XXXClass.class) return false;

用被比较对象的class对象和当前对象的class比较,看起来是没有问题,但是,如果这个类的子类没有重新实现equals方法,那么子类在比较的时候,obj.getClass() 肯定不等于XXXCalss.class,也就是子类的equals将无效,所以if(obj.getClass() != this.getClass()) return false;才是正确的比较。
 
2008-07-26
java对象equals方法的重写
什么时候需要重写equals()?
  我们知道每一个java类都继承自Object类,equals()是Object类中提供的方法之一。那么,让我们先来看看Object#equals()在Java中的原代码:

public boolean equals(Object obj)
{
  return (this == obj);
}

可以看出,只有当一个实例等于它本身的时候,equals()才会返回true值。通俗地说,此时比较的是两个引用是否指向内存中的同一个对象,也可以称做是否实例相等。而我们在使用equals()来比较两个指向值对象的引用的时候,往往希望知道它们逻辑上是否相等,而不是它们是否指向同一个对象。在这样的情况下, 如果超类也没有重写equals()以实现期望的行为,这时我们就需要重写equals方法。而且这样做也使得这个类的实例可以被用做映射表(map)的键,或者集合(set)的元素,并使映射表或者集合表现出预期的行为。
Object类提供的equals方法只是一个很简单的,不能适应应用程序有特殊要求的情况。
  比如网络对象,带有volatile属性的对象,或是带有多层子对象的复合对象,等等,是不能像String一类的对象进行简单比较的,所以提供了这样一个机制,就像serializable接口一样,既有默认的序列化方法,也提供了程序自己定制,覆盖默认方式的可能性。
  Object仅仅提供了一个对引用的比较,如果两个引用不是同一个那就返回false,这是无法满足大多数对象比较的需要的,所以要覆盖。

怎样重写equals()方法?
  重写equals()方法看起来非常简单,但是有许多改写的方式会导致错误,并且后果非常严重。要想正确改写equals()方法,你必须要遵守它的通用约定。下面是约定的内容,来自java.lang.Object的规范:
equals方法实现了等价关系(equivalence relation):
1. 自反性:对于任意的引用值x,x.equals(x)一定为true。
2. 对称性:对于任意的引用值x 和 y,当x.equals(y)返回true时,
  y.equals(x)也一定返回true。
3. 传递性:对于任意的引用值x、y和z,如果x.equals(y)返回true,
  并且y.equals(z)也返回true,那么x.equals(z)也一定返回true。
4. 一致性:对于任意的引用值x 和 y,如果用于equals比较的对象信息没有被修
  改,多次调用x.equals(y)要么一致地返回true,要么一致地返回false。
5. 非空性:对于任意的非空引用值x,x.equals(null)一定返回false。
接下来我们通过实例来理解上面的约定。我们首先以一个简单的非可变的二维点类作为开始:
public class Point{
  private final int x;
  private final int y;
  public Point(int x, int y){
    this.x = x;
    this.y = y;
  }

  public boolean equals(Object o){
    if(!(o instanceof Point))
      return false;
    Point p = (Point)o;
      return p.x == x && p.y == y;
  }

}


假设你想要扩展这个类,为一个点增加颜色信息:
public class ColorPoint extends Point{
  private Color color;
  public ColorPoint(int x, int y, Color color){
    super(x, y);
    this.color = color;
  }

  //override equasl()

  public boolean equals(Object o){
    if(!(o instanceof ColorPoint))
     return false;
    ColorPoint cp = (ColorPoint)o;
    return super.equals(o) && cp.color==color;
  }
}


  我们重写了equals方法,只有当实参是另一个有色点,并且具有同样的位置和颜色的时候,它才返回true。可这个方法的问题在于,你在比较一个普通点和一个有色点,以及反过来的情形的时候,可能会得到不同的结果:
public static void main(String[] args){
  Point p = new Point(1, 2);
  ColorPoint cp = new ColorPoint(1, 2, Color.RED);
  System.out.println(p.equals(cp));
  System.out.println(cp.eqauls(p));
}

运行结果:
true  
false
这样的结果显然违反了对称性,你可以做这样的尝试来修正这个问题:让ColorPoint.equals在进行“混合比较”的时候忽略颜色信息:
public boolean equals(Object o){
  if(!(o instanceof Point))
    return false;
  //如果o是一个普通点,就忽略颜色信息
  if(!(o instanceof ColorPoint))
    return o.equals(this);
  //如果o是一个有色点,就做完整的比较
  ColorPoint cp = (ColorPoint)o;
  return super.equals(o) && cp.color==color;
}

这种方法的结果会怎样呢?让我们先来测试一下:
public static void main(String[] args){
  ColorPoint p1 = new ColorPoint(1, 2, Color.RED);
  Point p2 = new Point(1, 2);
  ColorPoint p3 = new ColorPoint(1, 2, Color.BLUE);
  System.out.println(p1.equals(p2));
  System.out.println(p2.equals(p1));
  System.out.println(p2.equals(p3));
  System.out.println(p1.eqauls(p3));
}

运行结果:
true
true
true
false

  这种方法确实提供了对称性,但是却牺牲了传递性(按照约定,p1.equals(p2)和p2.eqauals(p3)都返回true,p1.equals(p3)也应返回true)。要怎么解决呢?事实上,这是面向对象语言中关于等价关系的一个基本问题。要想在扩展一个可实例化的类的同时,既要增加新的特征,同时还要保留equals约定,没有一个简单的办法可以做到这一点。新的解决办法就是不再让ColorPoint扩展Point,而是在ColorPoint中加入一个私有的Point域,以及一个公有的视图(view)方法:
public class ColorPoint{
  private Point point;
  private Color color;
  public ColorPoint(int x, int y, Color color){
    point = new Point(x, y);
    this.color = color;
  }

  //返回一个与该有色点在同一位置上的普通Point对象
  public Point asPoint(){
    return point;
  }

  public boolean equals(Object o){
    if(o == this)
     return true;
    if(!(o instanceof ColorPoint))
     return false;
    ColorPoint cp = (ColorPoint)o;
    return cp.point.equals(point)&&
             cp.color.equals(color);

  }
}


  还有另外一个解决的办法就是把Point设计成一个抽象的类(abstract class),这样你就可以在该抽象类的子类中增加新的特征,而不会违反equals约定。因为抽象类无法创建类的实例,那么前面所述的种种问题都不会发生。

重写equals方法的要点:
1. 使用==操作符检查“实参是否为指向对象的一个引用”。
2. 使用instanceof操作符检查“实参是否为正确的类型”。
3. 把实参转换到正确的类型。
4. 对于该类中每一个“关键”域,检查实参中的域与当前对象中对应的域值是否匹
  配。对于既不是float也不是double类型的基本类型的域,可以使用==操作符
  进行比较;对于对象引用类型的域,可以递归地调用所引用的对象的equals方法;
  对于float类型的域,先使用Float.floatToIntBits转换成int类型的值,
  然后使用==操作符比较int类型的值;对于double类型的域,先使用
  Double.doubleToLongBits转换成long类型的值,然后使用==操作符比较
  long类型的值。
5. 当你编写完成了equals方法之后,应该问自己三个问题:它是否是对称的、传
  递的、一致的?(其他两个特性通常会自行满足)如果答案是否定的,那么请找到
  这些特性未能满足的原因,再修改equals方法的代码。

你可能感兴趣的:(jdk,算法,网络应用,sun,FP)