عرض عملي: لوحة متصدّرين بمقارِنات متعددة المفاتيح

Written Explanation

The plan

We will take six steps. Keep one source file for Player and one for the leaderboard code.

1. Create Player with an id, a name, and a score.
2. Build a list with tied scores and sort by score only.
3. Add the second key.
4. Plant the subtraction mistake and watch it fail.
5. Write topN.
6. Put the players in a TreeSet using the same comparator.

Step 1: the Player class

public class Player {
    private final int id;
    private final String name;
    private final int score;

    public Player(int id, String name, int score) {
        this.id = id; this.name = name; this.score = score;
    }
    public int getId() { return id; }
    public String getName() { return name; }
    public int getScore() { return score; }

    @Override
    public String toString() { return name + ":" + score; }
}

Notice what is missing: Player does not implement Comparable. A player has no single obvious "natural" order (by score? by name?), so we keep every order outside the class, in comparators. That is the lesson 2 rule of thumb. The id field is there for the final tie-break later.

Step 2: score only, and the ties

List<Player> players = List.of(
        new Player(1, "Mona", 90), new Player(2, "Zed", 90),
        new Player(3, "Ali", 70),  new Player(4, "Bob", 90),
        new Player(5, "Cy", 70),   new Player(6, "Dina", 55));

List<Player> scoreOnly = new ArrayList<>(players);
scoreOnly.sort(Comparator.comparingInt(Player::getScore).reversed());
System.out.println("score only: " + scoreOnly);

We copy into an ArrayList, because a list from List.of cannot be sorted (it is unmodifiable). Output:

score only: [Mona:90, Zed:90, Bob:90, Ali:70, Cy:70, Dina:55]

Scores are in the right order, but the three 90s are in whatever order they were added. That is the stable sort at work: ties keep their input order. A user would find "Mona, Zed, Bob" an arbitrary order.

Step 3: add the second (and third) key

static final Comparator<Player> BY_RANK =
        Comparator.comparingInt(Player::getScore).reversed()
                  .thenComparing(Player::getName)
                  .thenComparingInt(Player::getId);

reversed() is called directly after the score key, so only the score is flipped (lesson 3). The name is the visible tie-break. The id is a last, invisible tie-break for players who share both name and score: it keeps the order fully deterministic and, as you will see in step 6, keeps the TreeSet honest.

Step 4: the planned mistake

A teammate writes the "obvious" descending comparator:

Comparator<Player> risky = (a, b) -> b.getScore() - a.getScore();
List<Player> extremes = new ArrayList<>(List.of(
        new Player(8, "High", Integer.MAX_VALUE), new Player(9, "Low", -5)));
extremes.sort(risky);
System.out.println("risky:      " + extremes);

On ordinary scores (0 to 100) it works, so the tests pass. With extreme values, the real output is:

risky:      [Low:-5, High:2147483647]

The player with the highest possible score is last. Why? When compare is asked about the two players, it calculates -5 - 2147483647, whose exact value is -2,147,483,652. That does not fit in an int, so it wraps around to a positive 2,147,483,644, and the sort concludes "High goes after Low". The safe versions never subtract:

extremes.sort(Comparator.comparingInt(Player::getScore).reversed());
// safe: [High:2147483647, Low:-5]

In your own code, scores may also be points, money in cents, or timestamps in milliseconds, where large values are not exotic. Never subtract in compare.

Step 5: top N

static List<Player> topN(List<Player> players, int n) {
    List<Player> sorted = new ArrayList<>(players);
    sorted.sort(BY_RANK);
    return new ArrayList<>(sorted.subList(0, Math.min(n, sorted.size())));
}

Three small choices matter here. We copy the input before sorting, so the caller's list is not rearranged as a side effect. We cap the end index with Math.min, so that asking for 10 from 6 players works. And we copy the subList view into a new list, so the result stays valid even if sorted changes. Running it:

top 3:      [Bob:90, Mona:90, Zed:90]
top 10:     [Bob:90, Mona:90, Zed:90, Ali:70, Cy:70, Dina:55]

The three-way tie at 90 is resolved by name, so the top 3 is the same every run, no matter how the input was ordered.

Step 6: the same ranking in a TreeSet

Set<Player> set = new TreeSet<>(BY_RANK);
set.addAll(players);
set.add(new Player(7, "Bob", 90));   // a second, different Bob with the same score
System.out.println("tree set:   " + set + " size=" + set.size());

tree set:   [Bob:90, Bob:90, Mona:90, Zed:90, Ali:70, Cy:70, Dina:55] size=7

Both Bobs are present, because the id separates them. Without thenComparingInt(Player::getId) the second Bob would compare as 0 against the first and the set would silently refuse him, giving size 6. A TreeSet is a handy way to keep a leaderboard sorted as players arrive, since each add puts the player in the right place.