第8条:覆盖equals时请遵守通用约定

第8条:覆盖equals时请遵守通用约定

引言:尽管Object是一个具体类,但是设计它主要是为了拓展。它所有的非final方法(equals、hashCode、toString、clone和finalize)都有明确的通用约定(general contract),因为它们被设计成是要被覆盖(override)的。任何一个类,它在覆盖这些方法的时候,都有责任遵守这些通用的约定;如果不能做到这一点,其它依赖于这些约定的类(例如HashMap和HashSet)就无法结合该类一起正常运作。

覆盖equals方法看起来似乎很简单,但是有很多覆盖方式会导致错误,并且后果非常的严重。最容易避免这类问题的办法就是补覆盖equals方法,在这种情况下,类的每个实例都只是与它自身相等。如果满足以下任何一个条件,这正是所期望的结果:

(1)类的每个实例本质上都是唯一的。对于代表活动实体而不是值(value)的类来说,例如Thread。Object提供的equals实现对于这些类来说正是正确的行为。

 public class Singleton {
private static Singleton singleton; private Singleton() {} public static Singleton getInstance() {
if(singleton == null)
singleton = new Singleton();
return singleton;
}
}
 Singleton singleton1 = Singleton.getInstance();
Singleton singleton2 = Singleton.getInstance();
System.out.println(singleton1.equals(singleton2));
true

(2)不关心类是否提供了“逻辑相等(logical equality)”的测试功能。例如,java.util.Random覆盖了equals,以检查两个Random实例是否产生相同的随机数列,但是设计者并不认为客户需要或者期望这样的功能。在这样的情况下,从Object继承的equals实现就已经足够了。

(3)超类已经覆盖了equals,从超类继承过来的行为对于子类也是合适的。例如,大多数的Set实现都从AbstractSet继承equals实现,List实现从equals实现,Map实现从AbstractMap继承equals实现。

(4)类是私有的或者包级私有的,可以确定它的equals方法永远不会被调用。在这种情况下,无疑是应该覆盖equals的,以防止它被意外调用。

 @Override
public boolean equals(Object obj) {
throw new AssertionError(); //Method is never called
}

那么,什么时候应该覆盖Object.equals呢?如果类具有自己特定的“逻辑相等”概念(不等同于对象等同的概念),而且超类还没有覆盖equals以实现期望的行为,这时候我们就需要覆盖equals方法。这通常属于“值类(value class)”的情形。值类仅仅是一个表示值得类,例如Integer或者Date。程序员在利用equals方法来比较值对象的引用时,希望知道它们在逻辑上是否相等,而不是想了解它们是否指向同一个对象。为了满足程序员的这种需求,不仅必需覆盖equals方法,而且这样做也使得这个类的实例可以被用作映射表(map)的键(key),或者集合(set)的元素,使映射或者集合表现出预期的行为。

有一种“值类”不需要覆盖equals方法,即用例受控确保“每个值至多只存在一个对像”的类,枚举类型就属于这种类。对于这样的类而言,逻辑相同与对象等同是同一个概念,因此Object的equals方法等同于逻辑意义上的equals方法。

在覆盖equals方法的时候,你必须要遵守它的通用约定。下面是约定的内容:

equals方法实现了等价关系(equivalence relation):

  • 自反性(reflexive):对于任何非null的引用值x,x.equals(x)必须返回true。
  • 对称性(symmetric):对于任何非null的引用值x与y,当且仅当y.equals(x)返回true时,x.equals(y)必须返回true。
  • 传递性(transitive):对于任何非null的引用值x、y和z,如果x.equals(y)返回为true,并且y.equals(z)也返回true,那么x.equals(z)也必须返回true。
  • 一致性(consistent):对于任何非null的引用值x和y,只要equals的比较操作在对象中所用的信息没有被修改,多次调用x.equals(y)就会一致地返回true,或者一致地返回false。
  • 对于任何非null的引用值x,x.equals(null)。

对于上述性质的部分解释

自反性:对象必须等于其自身

违反对称性:

 public class CaseInsensitiveString {
private final String s;
public CaseInsensitiveString(String s) {
if(s == null)
throw new NullPointerException();
this.s = s;
}
/*
* 1.equals()函数:主要是区分“比较的字符串” 大小写和长度时候相同,比较的类型可以是Object类型。
* 2.equalsIgnoreCase()函数:比较的参数只能是字符串,这里只要字符串的长度相等,字母的大小写是
* 忽略的。认为A-Z和a-z是一样的。
*/
@Override //违反对称性
public boolean equals(Object o) {
if(o instanceof CaseInsensitiveString)
return s.equalsIgnoreCase(
((CaseInsensitiveString) o).s);
if(o instanceof String)
return s.equalsIgnoreCase((String) o);
return false;
}
}

在这个类中,equals方法的意图非常好,它企图与普通的字符串(String)对象进行互操作。假设我们有一个不区分大小写的字符串和一个普通的字符串:

 CaseInsensitiveString cis = new CaseInsensitiveString("Polish");
String s = "polish";
System.out.println(cis.equals((Object)s));
true

正如所料,cis.equals((Object)s)返回为true,虽然CaseInsensitiveString类中的equals方法知道普通的字符串(String)对象,但是String中的equals方法却并不知道不区分大小写的字符串,因此s.equals((Object)cis)返回为false,显然违反了对称性。假设你把不区分大小写的字符串放在一个集合中:

 List<CaseInsensitiveString> list = new ArrayList<CaseInsensitiveString>();
list.add(cis);

此时的list.contains(s)会返回什么结果呢?在Sun当前的实现中,它碰巧返回false,但是只是这个特定的实现得出的结果而已。在其它的实现中,它有可能返回true,或者抛出一个运行时(runtime)异常。一旦违反了equals约定,当其他对象面对你的对象时,你完全不知道这些对象的行为会怎么样。

为了解决这个问题,只需把企图与String互操作的这段代码从equals方法找中去掉就可以了。这样做之后,就可以重构该方法,使它变成一条单独的返回语句:

 public static void main(String[] args) {
CaseInsensitiveString cis = new CaseInsensitiveString("Polish");
String s = "polish";
System.out.println(cis.equals((Object)s));
}

传递性:子类增加的信息会影响到equals的比较结果。我们首先以一个简单的不可变的二维整数型Point类作为开始:

 public class Point {
private final int x;
private final int y;
public Point(int x, int y) {
this.x = x;
this.y = y;
}
@Override
public boolean equals(Object obj) {
if(!(obj instanceof Point))
return false;
Point p = (Point)obj;
return p.x == x && p.y == y;
}
}

假设你想要扩展这个类,为一个点添加颜色信息:

 public class ColorPoint extends Point {
private final Color color; public ColorPoint(int x, int y, Color color) {
super(x, y);
this.color = color;
}
}

equals方法会怎么样呢?如果完全不提供equals方法,而是直接从Point继承过来,在equals做比较的时候颜色信息就被忽略掉了。这样做虽然不会违反equals的约定,但是很明显这是无法接受的。假设你编写了一个equals方法,只有当它的参数是一个有色点,并且具有相同的位置和颜色时,它才会返回true:

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

这个方法的问题在于,你在比较普通点和有色点,以及相反的情形时,可能会得到不同的结果。前一种比较忽略了颜色信息,而后一种比较则总是返回false,因为参数的类型不正确。为了直观的说明问题所在,我们创建一个普通点和有色点:

 Point p = new Point(1,2);
ColorPoint cp = new ColorPoint(1,2,Color.RED);
System.out.println(p.equals(cp));
System.out.println(cp.equals(p));

运行结果如下:

true
false

你可以做这样的尝试来修正这个问题,让ColorPoint.equals在进行“混合比较”时忽略颜色信息:

 @Override
public boolean equals(Object obj) {
if(!(obj instanceof Point))
return false;
//如果obj是一个普通点,则比较时忽略颜色信息
if(!(obj instanceof ColorPoint))
return obj.equals(this);
//如果obj是一个有色点,进行全面比较
return super.equals(obj) && ((ColorPoint) obj).color == color;
}

这种方法确实提供了对称性,但是却牺牲了传递性:

 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(p3));
System.out.println(p1.equals(p3));

运行结果如下:

true
true
false

很显然,这违反了传递性,前两种比较不考虑颜色信息(色盲),而第三种比较则考虑了颜色信息。

怎么解决呢?事实上,这是面向对象语言中关于等价关系的一个基本问题。我们无法在拓展可实例化的类的同时,既增加新的值组件,同时又保留equals约定,除非愿意放弃面向对象的抽象所带来的优势。

你可能听说,在equals方法中庸getClass()测试代替instanceof测试,可以扩展可实例化的类和增加新的值组件,同时保留equals约定:

 @Override
public boolean equals(Object obj) {
if(obj == null || obj.getClass() != getClass())
return false;
Point p = (Point) obj;
return p.x == x && p.y == y;
}

这段程序只有当对象具有相同的实现时,才能使对象等同。虽然这样也不算太糟糕,但是结果却是无法接受的。

假设我们要编写一个方法,以检验某个整值点是否处在单位元中。下面是可以采用的其中一种方法:

 private static final Set<Point> unitCircle;
static {
unitCircle = new HashSet<Point>();
unitCircle.add(new Point(1,0));
unitCircle.add(new Point(0,1));
unitCircle.add(new Point(-1,0));
unitCircle.add(new Point(0,-1));
}
public static boolean onUnitCircle(Point p) {
return unitCircle.contains(p);
}

虽然这可能不是实现这种功能的最快方法,不过它的效果很好。但是假设你通过某种不添加值组件的方式扩展了Point,例如让它的构造器记录创建了多少个实例:

 public class CounterPoint extends Point {
private static final AtomicInteger counter =
new AtomicInteger();
public CounterPoint(int x,int y) {
super(x,y);
counter.incrementAndGet();
}
public int numberCreated() {return counter.get();};
}

虽然没有一种令人满意的办法可以既扩展不可实例化的类,有增加组件,但还是有一种不错的权宜之计(workaround):复合优先于继承,我们不在让ColorPoint扩展Point,而是在ColorPoint中加入一个私有的Point域,以及一个公有视图(view)方法,此方法返回一个与该有色点处在相同位置的普通Point对象:

 public class ColorPoint {
private final Color color;
private final Point point;
public ColorPoint(int x,int y,Color color) {
if(color == null)
throw new NullPointerException();
point = new Point(x,y);
this.color = color;
}
//返回这个颜色点的视图
public Point asPoint() {
return point;
}
@Override
public boolean equals(Object obj) {
if(!(obj instanceof ColorPoint))
return false;
ColorPoint cp = (ColorPoint) obj;
return cp.point.equals(point) && cp.color.equals(color);
}
}

注意:(1)在Java的平台库中,有一些类扩展了可实例化的类,并添加了新的值组件。例如,java.sql.Timestamp对java.util.Date进行了扩展,并增加了nanoseconds域。Timestamp的equals确实违反了对称性,所以在平时的代码编写中尽量不要将这两者混合在一起,否则出现问题会很难调试。

(2)你可以在一个抽象(abstract)类的子类中增加新的值组件,而不会违反equals约定。

一致性:如果两个对象相等,那就必须始终保持相等,除非它们中有一个对象被修改了。无论类是否是不可变的,都不要使equals方法依赖于不可靠的资源,如果违反了这条禁令,要想满足一致性的要求就非常困难了。

非空性:指所有的对象都必须不等于null。许多类的equals方法都通过一个显示的null测试来防止这种情况:

 @Override
public boolean equals(Object obj) {
if(obj == null)
return false;
... }

这项测试是不必要的,为了测试其参数的等同性,equals方法必须先把参数转换成适当的类型,以便调用它的访问方法(accessor),或者访问它的域。转换之前,需要用instanceof操作符,检查其参数是否为正确的类型:

 @Override
public boolean equals(Object obj) {
if(!(obj instanceof MyType))
return false;
MyType mt = (MyType) obj;
...
}

结合这些所有的要求,得出了以下实现高质量equals方法的诀窍:

1、使用==操作符检查“参数是否为这个对象的引用”。

2、使用instanceof操作符检查“参数是否为正确的类型”。

3、把参数转换成正确的类型。

4、对于该类中的每个“关键(significant)”域,检查参数中的域是否与该对象中对应的域相匹配。

5、当你编写完了equals方法之后,应该问自己三个问题:它是否是对称的、传递的、一致的,并且编写单元测试对其进行检查。

6、覆盖equals时总要覆盖hashCode

7、不要企图让equals方法过于智能。

8、不要将equals声明中的Object对象替换成其它的类型。

上一篇:2-红帽RHEL 7起步


下一篇:nodejs的mysql模块学习(十)连接池集群配置选项