读《Effective Java》有感。本文分析了equals方法在java编写中的一些原则，以及分析了jdk源码中存在的一个设计缺陷的案例
上面我们写一个单元测试，用于测试timestamp和date对象之间的equals方法的对称性。
根据equals的对称性原则，如果俩个非空对象a和b，如果存在a.equals(b)为true，那么一定存在b.equals(a)为true。但我们得到的运行结果却大不一样：date和ts equals结果为true，ts和date的equals的结果为false。
基于我们对equals对称性原则的认知，上述结果明显和原则不符，那么是什么原因导致这种现象的发生，为什么jdk又允许了这种现象的发生呢。
这里补充一个知识点：Timestamp的父类是java.util.Date，然后在timestamp中加了一个纳秒属性
分析问题之前，我们需要先了解equals的几大原则：
对称性（Symmetry）：如果两个对象相互比较，比如 a.equals(b) ，则 b.equals(a) 也应该返回相同的结果。换句话说，对于任意的非空对象 a 和 b，如果 a.equals(b) 返回 true，则 b.equals(a) 也应该返回 true。
自反性（Reflexivity）：一个对象通过调用其自身的 "equals" 方法应该返回 true。换句话说，对于任意的非空对象 a，a.equals(a) 应该返回 true。
传递性（Transitivity）：如果对象 A 和对象 B 相等，并且对象 B 和对象 C 相>等，那么对象 A 和对象 C 也应该相等。换句话说，如果 a.equals(b) 返回 true，b.equals(c) 也返回 true，则 a.equals(c) 应该返回 true。
一致性（Consistency）：对于任意的非空对象 a 和 b，如果对象的状态没有发生变化，那么多次调用 a.equals(b) 应该始终返回相同的结果。换句话说，如果 a 和 b 的内容没有发生变化，则多次调用 a.equals(b) 应该返回相同的结果。
非空性（Non-nullity）：对于任意的非空对象 a，a.equals(null) 应该返回 false。换句话说，对象和 null 比较应该始终返回 false。
而我们上述的问题牵扯的就是第一个原则：对称性。
下面，我们看下Timestamp和Date在设计上为何违反了equals的对称性
/**
* Tests to see if this <code>Timestamp</code> object is
* equal to the given object.
*
* This version of the method <code>equals</code> has been added
* to fix the incorrect
* signature of <code>Timestamp.equals(Timestamp)</code> and to preserve backward
* compatibility with existing class files.
*
* Note: This method is not symmetric with respect to the
* <code>equals(Object)</code> method in the base class.
*
* @param ts the <code>Object</code> value to compare with
* @return <code>true</code> if the given <code>Object</code> is an instance
* of a <code>Timestamp</code> that
* is equal to this <code>Timestamp</code> object;
* <code>false</code> otherwise
*/
public boolean equals(java.lang.Object ts) {
if (ts instanceof Timestamp) {
return this.equals((Timestamp)ts);
} else {
return false;
}
}
注意到方法注释上有一句话很重要：
This version of the method <code>equals</code> has been added to fix the incorrect signature of <code>Timestamp.equals(Timestamp)</code> and to preserve backward
所以Timestamp还提供了另外一个equals方法，专门用来比较Timestamp类型的，如下：
/**
* Tests to see if this <code>Timestamp</code> object is
* equal to the given <code>Timestamp</code> object.
*
* @param ts the <code>Timestamp</code> value to compare with
* @return <code>true</code> if the given <code>Timestamp</code>
* object is equal to this <code>Timestamp</code> object;
* <code>false</code> otherwise
*/
public boolean equals(Timestamp ts) {
if (super.equals(ts)) {
if (nanos == ts.nanos) {
return true;
} else {
return false;
}
} else {
return false;
}
}
综上我们可以进行简单总结下：
- 重写的Object的equals方法，如果传入对象ts是Timestamp则调用重载的equals方法进行比较，如果不是Timestamp类型，则直接返回false。
- 重载的equals方法主要是调用父类（java.util.Date）的equals方法，之后在比较timestamp的nanos
简单提供一个图助于理解：
为了方便比较，下面截取了Date类型的equals方法
/**
* Compares two dates for equality.
* The result is <code>true</code> if and only if the argument is
* not <code>null</code> and is a <code>Date</code> object that
* represents the same point in time, to the millisecond, as this object.
* <p>
* Thus, two <code>Date</code> objects are equal if and only if the
* <code>getTime</code> method returns the same <code>long</code>
* value for both.
*
* @param obj the object to compare with.
* @return <code>true</code> if the objects are the same;
* <code>false</code> otherwise.
* @see java.util.Date#getTime()
*/
public boolean equals(Object obj) {
return obj instanceof Date && getTime() == ((Date) obj).getTime();
}
Date类的equals的逻辑表示：
- 如果obj是Date类型或者obj的父类为Date类型
- 将obj强转为Date类型后的time和this.time相等则返回true。
上述二者缺一不可。
我们通过分析Timestamp和Date的equals方法，可以发现，他们为什么会返回不一样的结果：
- Timestamp的equals方法不仅会先比较类型，还会比较time属性，还会比较另外一个nanos属性是否相等。
- Date的equals方法只会比较time属性。
同时正是因为timestamp和date类型之间存在者继承关系，所以导致在判断类型的时候timestamp instanceof date可以通过，而反之则不通过，这也是违反equals对称性的最大的一个原因。
以上的分析我们明白了在jdk中timestamp和date之间equals对称性之间的纠缠，但文章的研究还未结束，其实我们可以修改Timestamp源码来解决这个对称性问题。下面是修改后的源码：
public class MyTimestamp extends Timestamp {
public MyTimestamp(long time) {
super(time);
}
@Override
public boolean equals(Object ts) {
if (ts instanceof Timestamp) {
return this.equals((Timestamp)ts);
} else if (ts instanceof Date) {
return this.getTime() == ((Date) ts).getTime();
} else {
return false;
}
}
}
我们来编写测试来测试我们自己构造的Timestamp：
可以看到测试是通过的，也就是说我们修改后的Timestamp的equals源码增加了对Date类型的支持后，就解决了对称性的问题。
但真的有这么简单吗？我们能想到的自然前辈们也能想到，那么这种写法会有什么问题呢？我们在看一个单元测试，如下：
单元测试中，我们声明了三个对象，date、myTimestamp1、myTimestamp2，通过我们对前一个单元测试的推断，date和myTimestamp1以及date和myTimestamp2是互相等价的，但是32行myTimestamp1和myTimestamp2却不想等。
文章开头我们提及过，equals一共有五个原则，我们上面分析了对称性，这里涉及到的就是传递性。如果o1和o2相等，o2和o3相等，那么o1等于o3，这里的o2可以带入为date，o1和o3分别为myTimestamp1和myTimestamp2
所以我们修改过的源码虽然能解决对称性，但是无法解决传递性，其实在这里，因为date和timestamp存在继承关系，必然无法满足equals的其中之一的准则。这是jdk设计上的一个缺陷。
关于此类问题，在《Effective Java》第二版一书中33页有提供相关解释。
事实上，这是面向对象语言中关于等价关系的一个基本问题。我们无法在拓展可实例化的类的同时，既增加新的值组件，同时又保留equals约定，除非愿意放弃面向对象的抽象所带来的优势。
同时还提供了相关的解决方案：
复合优先于继承
目前java相关组件和框架编写代码中，对于非业务（框架和公用jar包）的对象模型，一般都使用复合来替代继承。
到这里，本文通过一个简单的例子分析了jdk中一个坏的例子去了解equals在设计上需要满足的准则。让我们在后续的项目代码中保证合理的设计是研发必要的考虑。
下面是出自于《Effective Java》一书中对于实现高质量equals方法的诀窍
- 使用==操作符检查“参数是否为这个对象的引用”
- 使用instanceof操作符检查“参数是否为正确的类型”
- 把参数转换成正确的类型
- 对于该类中的每个“关键（significant）”域，检查参数中的域是否与该对象对应的域相匹配。
- 当你编写完成了equals方法之后，应该问自己三个问题：它是否是对称的、传递的、一致的？并且不要只是自问，还需要编写单元测试来检验这些特性
