jdk源码阅读之Comparable接口区别于Comparator

附上源码

/**
 * This interface imposes a total ordering on the objects of each class that
 * implements it.  This ordering is referred to as the class's natural
 * ordering, and the class's compareTo method is referred to as
 * its natural comparison method.

* * Lists (and arrays) of objects that implement this interface can be sorted * automatically by {@link Collections#sort(List) Collections.sort} (and * {@link Arrays#sort(Object[]) Arrays.sort}). Objects that implement this * interface can be used as keys in a {@linkplain SortedMap sorted map} or as * elements in a {@linkplain SortedSet sorted set}, without the need to * specify a {@linkplain Comparator comparator}.

* * The natural ordering for a class C is said to be consistent * with equals if and only if e1.compareTo(e2) == 0 has * the same boolean value as e1.equals(e2) for every * e1 and e2 of class C. Note that null * is not an instance of any class, and e.compareTo(null) should * throw a NullPointerException even though e.equals(null) * returns false.

* * It is strongly recommended (though not required) that natural orderings be * consistent with equals. This is so because sorted sets (and sorted maps) * without explicit comparators behave "strangely" when they are used with * elements (or keys) whose natural ordering is inconsistent with equals. In * particular, such a sorted set (or sorted map) violates the general contract * for set (or map), which is defined in terms of the equals * method.

* * For example, if one adds two keys a and b such that * {@code (!a.equals(b) && a.compareTo(b) == 0)} to a sorted * set that does not use an explicit comparator, the second add * operation returns false (and the size of the sorted set does not increase) * because a and b are equivalent from the sorted set's * perspective.

* * Virtually all Java core classes that implement Comparable have natural * orderings that are consistent with equals. One exception is * java.math.BigDecimal, whose natural ordering equates * BigDecimal objects with equal values and different precisions * (such as 4.0 and 4.00).

* * For the mathematically inclined, the relation that defines * the natural ordering on a given class C is:

 *       {(x, y) such that x.compareTo(y) <= 0}.
 * 
The quotient for this total order is:
 *       {(x, y) such that x.compareTo(y) == 0}.
 * 
* * It follows immediately from the contract for compareTo that the * quotient is an equivalence relation on C, and that the * natural ordering is a total order on C. When we say that a * class's natural ordering is consistent with equals, we mean that the * quotient for the natural ordering is the equivalence relation defined by * the class's {@link Object#equals(Object) equals(Object)} method:
 *     {(x, y) such that x.equals(y)}. 

* * This interface is a member of the * * Java Collections Framework. * * @param the type of objects that this object may be compared to * * @author Josh Bloch * @see java.util.Comparator * @since 1.2 */

这一接口会对实现了它的类施加一个整体的顺序.这一顺序被认为是类的自然顺序,类的比较方法compareTo()也被认为是自然比较方法

实现这一接口的对象中,List类对象使用Collections.sort方法实现自动排序(升序),数组使用Arrays.sort()方法实现升序排序.实现这一接口的对象在有序Map中被用来作为Key进行排序的;在有序Set中,是作为set集合中的元素排序的.而使用这些方法时,我们并不需要指定比较器comparator

对于类C的任意变量e1和e2,当且仅当e1.compareTo(e2) == 0的和e1.equals(e2)有相同的返回值时,类的自然排序才能被认为是和equals方法的 结果保持一致的.
注意:虽然e.equals(null)返回值为false,但是null不是任何类的实例,所以如果调用方法e.compareTo(null)应该抛出异常NullPointerException

我们强烈建议(尽管并不是必须的):自然排序应该和equals结果保持一致(这是因为自然排序用到了compare方法,这里的意思是需要满足关系: e1.compareTo(e2) == 0的和e1.equals(e2)有相同的返回值).这是因为没有明确比较器的有序set(和有序map) (什么叫没有明确比较器?对于TreeSet和TreeMap,都有多个实例构造函数,而其中有一个无参构造函数,就指定了比较器comparator = null;同时, 这也说明了,如果你想在建立有序set或者有序map时就指定它的排序方法,那么可以给构造函数传入一个比较器参数即可.),如果自然排序不能和equals方法 保持一致,那么它们会表现出一些诡异的行为.而且,这样的有序set(或者map)和equals中通用规范是矛盾的。

举个例子:如果向一个没有明确比较器的有序set中添加2个值a和b(a.equals(b)值为false,而 a.compareTo(b) == 0 值为true(a==b)), 那么第二次的add操作会失败,因为从有序set的角度看,a和b是等值的.

实质上,所有实现了Comparable接口的java核心类,都满足自然排序的要求.唯一的例外类是:BigDecimal类.它的自然排序要求是:值相等而精度是不等的. 所以,精度不同但值相同的两个BigDecimal对象,它们的equals方法返回值应该为true,而compare()方法应该返回0:

类C上面的等价关系,自然排序是对类C上面的元素整体的一个排序,这符合compareTo的通用规范. 当我们说一个类的自然排序是和equals结果保持一致.那就意味着自然排序是由这个类的equals方法定义的等价关系.


public interface Comparable {

    public int compareTo(T o);
}

将当前对象a和指定对象b进行比较.
a>b:返回正数;
a=b:返回0;
a

实现这一接口的类必须保证对于任意的x和y,都应该满足的条件是:sgn(x.compareTo(y)) == -sgn(y.compareTo(x)) 这意味如果y.compareTo(x)抛出异常,则x.compareTo(y)必须抛出异常.

实现这个接口的类还必须保证:联系是具有传递性的: 如果: x.compareTo(y)>=0 && y.compareTo(z)>=0成立,则:x.compareTo(z)>=0也成立.

最后,实现这个的类必须保证:对于任意的z,如果x.compareTo(y)==0成立,则sgn(x.compareTo(z)) == sgn(y.compareTo(z))也成立.

我们强烈建议,但并非严格约定:x.compareTo(y)==0和x.equals(y)的返回值一致. 通常,任何实现了Comparable接口但违反了这一条件的类应该明确的表明这一事实. 作为这一事实的提醒语言,它可以这样写: 注意:这个类的自然排序并没有和equals结果保持一致.

在前面的表述中,用到的符号sgn是数学函数signum的一种表达式,它定义了:
sgn的参数为负数,返回-1;
sgn的参数为正数,返回1;
sgn的参数为0,返回0.

可能很多人会搞混与Comparatore的区别
Comparator是比较接口,我们如果需要控制某个类的次序,而该类本身不支持排序(即没有实现Comparable接口),那么我们就可以建立一个“该类的比较器”来进行排序,这个“比较器”只需要实现Comparator接口即可。

Comparable是排序接口,若一个类实现了Comparable接口,就意味着“该类支持排序”。而Comparator是比较器,我们若需要控制某个类的次序,可以建立一个“该类的比较器”来进行排序。

Comparable相当于“内部比较器”,而Comparator相当于“外部比较器”。

两种方法各有优劣, 用Comparable 简单, 只要实现Comparable 接口的对象直接就成为一个可以比较的对象,但是需要修改源代码。 用Comparator 的好处是不需要修改源代码, 而是另外实现一个比较器, 当某个自定义的对象需要作比较的时候,把比较器和对象一起传递过去就可以比大小了, 并且在Comparator 里面用户可以自己实现复杂的可以通用的逻辑,使其可以匹配一些比较简单的对象,那样就可以节省很多重复劳动了。

部分取材自:
https://www.cnblogs.com/xujian2014/p/5215082.html

整理不易,喜欢请点赞

你可能感兴趣的:(jdk源码阅读之Comparable接口区别于Comparator)