الترتيب الطبيعي باستخدام Comparable

Written Explanation

Some types already know their order

String, Integer, Long, Double and the other wrapper classes already implement Comparable. That is why this works without any extra code:

List<String> names = new ArrayList<>(List.of("Mona", "Ali", "Zed", "Bob"));
Collections.sort(names);
System.out.println(names);   // [Ali, Bob, Mona, Zed]

Strings sort by dictionary (character code) order, and numbers sort by value. A class you wrote, such as Book or Player, has no such rule. If you try Collections.sort on a list of them, the compiler refuses, because the elements are not Comparable.

The Comparable interface

Comparable<T> is a one-method interface from java.lang:

public interface Comparable<T> {
    int compareTo(T other);
}

A class that implements it declares: "I know how to compare myself with another T". The type parameter should normally be the class itself, so Book implements Comparable<Book>. (You met type parameters in BEG-031.)

What compareTo returns

a.compareTo(b) returns an int, and only its sign matters:

Do not rely on the exact value. It may be -1, 1, or any other number of the right sign. Oracle's documentation for Integer.compare says the same: it specifies only the sign.

Writing compareTo

For one numeric field, delegate to the wrapper's static compare method:

public class Book implements Comparable<Book> {
    private final String title;
    private final int year;

    Book(String title, int year) { this.title = title; this.year = year; }

    @Override
    public int compareTo(Book other) {
        return Integer.compare(year, other.year);
    }
}

This orders books by year, oldest first. Integer.compare(x, y) gives a negative number if x < y, zero if equal, and a positive number if x > y. For long, double, and char there are Long.compare, Double.compare, and Character.compare. For a String field, call its own compareTo.

Once the class is Comparable, three things work with no more code:

• Collections.sort(list) and list.sort(null) (passing null as the comparator means "use the natural ordering", according to the List documentation).
• new TreeSet<>(collection) and TreeSet's add, which keep elements in order.
• TreeMap keys, which are kept sorted.

Why not return a - b?

It is tempting to write return year - other.year;, because the sign of the difference looks right. It is wrong for large values, because int subtraction overflows: the result wraps around. With Integer.MAX_VALUE - (-5) the true answer is 2,147,483,652, which does not fit in an int, and Java wraps it to -2147483644: a negative number, so the larger value would be ranked first. Years are small and would never trigger this, but scores, ids, and amounts can. Integer.compare never has that problem, so always use it.

The rules of a good compareTo

The Java documentation asks every compareTo to follow a few rules. In plain words:

• Symmetric: if a comes before b, then b comes after a.
• Transitive: if a is before b and b is before c, then a is before c.
• Ties behave: if a and b tie, they must compare the same way against every other element.
• Null: x.compareTo(null) should throw a NullPointerException; it must not return a number.

Break these and sorting can give strange results or an exception.

Consistent with equals

A natural ordering is consistent with equals when a.compareTo(b) == 0 exactly when a.equals(b). The documentation recommends this but does not require it. It matters because a TreeSet and a TreeMap never call equals. They treat two elements that compare as 0 as the same element. If your ordering says "tie" for two objects that equals calls different, a TreeSet quietly keeps only one of them. The JDK's own example is BigDecimal: 4.0 and 4.00 compare as 0 but are not equals.