从Scala看canEqual与正确的的equals实现
Equals实现在Java中有着很多的问题（详见《所有的Equals方法实现都是错误的》），不过这些问题并非令人完全丧气。下面通过Scala作者的一篇文章中探讨equals实现以及canEqual的使用。
在 Effective Java 中，Joshua Bloch 提到，如果一个可实例化的类定义了 equals 方法。另有一个子类继承它，也定义了额外一些属性，并且 equals 方法中需要使用这些新定义的属性进行相等性判断。那么就不可能保证 equals 语义的正确。
相信看过 Effective Java 的人当年读到这里时都会觉得丧气。就好像完美的世界突然有了一个无法缝合的裂口。先不要完全丧失兴趣，看看下面的文章：
How to Write an Equality Method in Java （51CTO曾翻译此文为《所有的Equals方法实现都是错误的》）
这篇主要由 Scala 的作者 Martin Odersky 执笔的文章中提到了一个有意思的方法。每个类在定义 equals 时，首先先判断 canEqual 能不能校验通过。canEqual 的作用就是限定:只有当被比较的对象是当前对象的子类或同类时才能通过。
class Point {
// 属性定义
...
boolean canEqual(Object other) {
return (other instanceof Point);
}
@Override boolean equals(Object other) {
if (other instanceof Point) {
Point that = (Point) other;
if (that.canEqual(this) && ...) return true
}
return false;
}
}
子类的定义与父类相似。
也就是说，在这样的约定下，如果拿一个父类实例和子类实例用 equals 比较肯定会返回 false。关于这篇文章，有兴趣的话可以看看相应的讨论。
讨论主要集中在文章里的方法是否违背了 Liskov Substitution Principle (LSP)，以及如果违背了那么这个问题有多严重上。看过下面的分析后大家也许会觉得这种讨论没有太多意义。
我个人推荐这种 canEqual 方法。我说“方法”而不说“解决方案”是因为我觉得 Odersky 所描述的 equals 实现与 Bloch 本来所期望的 equals 逻辑模型并不一致。想像 Odersky 文章中的例子。有一个类 － 点（Point），及其子类 － 有色点（ColoredPoint）。如果一个有色点实例，其坐标与一个普遍点坐标一样，又因为有色点“是”点，所以这两点应该“相等”。大家都期望这样一个结论是成立的，所以当看到 Bloch 的结论时会觉得面向对象有其固有的自相矛盾之处。但是这样一个结论却并不是天然成立的。一个没有颜色的点与一个有颜色的点能相等吗？有人会说，如果 ColoredPoint 里面的 color 属性是一个枚举，而且那个子类被实例化成 Color.UNSPECIFIED（未指定的颜色），那么这两个点逻辑上就应该相等了吧。我认为，如果 ColoredPoint.color 可以有这样一个属性值的话，那么 Point 类就应该被定义为抽象类。Point 类此时实例化没有意义。换句话说，如果 Point 类可以实例化，且其子类 ColoredPoint 也可以有一个“未指定的颜色”，而且两者都定义了 equals，那么出现这种情况我认为是设计失败。
再看看 LSP。LSP 说，任何可以使用父类实例的地方都可以使用子类实例代替。这里并不违反 LSP，因为如果一个地方可以这样调用：
Point p = new Point();
if (p.equals(...)) {
...
}