Interfaces and Inner Classes - Java - page 661

The Comparable Interface
This subsection requires material on arrays from Chapter 6. If you have not yet cov-
ered Chapter 6, you can skip this section and the following Programming Example
without any loss of continuity. If you have read Chapter 6, you should not consider
this section to be optional.
In Chapter 6 (Display 6.11), we introduced a method for sorting a partially filled
array of base type double into increasing order. It is very easy to transform the code
into a method to sort into decreasing order instead of increasing order. (See Self-Test
Exercise 20 of Chapter 6 and its answer if this is not clear to you.) It is also easy to
modify the code to obtain methods for sorting integers instead of double s or sorting
strings into alphabetical order. Although these changes are easy, they seem to be, and
in fact are, a useless nuisance. All these sorting methods are essentially the same. The
only differences are the types of the values being sorted and the definition of the order-
ing. It would seem that we should be able to give a single sorting method that covers
all these cases. The Comparable interface lets us do this.
The Comparable interface is in the java.lang package and so is automatically avail-
able to your program. The Comparable interface has only the following method head-
ing that must be implemented for a class to implement the Comparable interface:

compareTo

public int compareTo(Object other);

The Comparable interface has a semantics, and it is the programmer's responsibility
to follow this semantics when implementing the Comparable interface. The semantics
says that compareTo returns
a negative number if the calling object “comes before” the parameter other ,
a zero if the calling object “equals” the parameter other ,
and a positive number if the calling object “comes after” the parameter other . 1
Almost any reasonable notions of “comes before” should be acceptable. In partic-
ular, all of the standard less-than relations on numbers and lexicographic ordering
on strings are suitable ordering for compareTo . (The relationship “comes after” is just
the reverse of “comes before.”) If you need to consider other ordering, the precise
rule is that the ordering must be a total ordering, which means the following rules
must be satisfied:
(Irreflexive) For no object o does o come before o .
(Trichotomy) For any two objects o1 and o2 , one and only one of the following
holds true: o1 comes before o2 , o1 comes after o2 , or o1 equals o2 .
(Transitivity) If o1 comes before o2 and o2 comes before o3 , then o1 comes before o3 .
The “equals” of the compareTo method semantics should coincide with the equals
methods if that is possible, but this is not absolutely required by the semantics.

1 Because the parameter to CompareTo is of type Object , an argument to CompareTo might not be an
object of the class being defined. If the parameter other is not of the same type as the class being
defined, then the semantics specifies that a ClassCastException should be thrown.