Robustness (прочность) в Java

Question

Добрый день! Недавно попалась весьма интересная задачка на Java. Которой хотел бы поделиться.

Дан следующий класс

public class RobustCheck {

    private final char first;
    private final char second;

    public RobustCheck(char first, char second) {
        this.first = first;
        this.second = second;
    }

    public boolean equals (RobustCheck b) {
        return this.first == b.first && this.second == b.second;
    }

    public int hashCode() {
        return 31 * first + second;
    }

    public static void main(String[] args) {
        Set<RobustCheck> s = new HashSet<RobustCheck>();
        for(int i=0; i<10; i++)
            for(char ch='a'; ch<='z'; ch++) {
                s.add(new RobustCheck(ch, ch));
            }
        System.out.println(s.size());
    }
}

И вопросы:

1. Почему программа возвращает размер 260 вместо 26? Как ее исправить?
2. Чего не хватает в данной программе, чтобы она указала ошибку на этапе компиляции?

Answer 1

Задача на знание краеугольных камней языка Java и недостатков в его дизайне. В данном случае метод RobustCheck#equals перегружает (overloading) метод Object#equals, в результате чего при сравнении объектов RobustCheck используется метод Object#equals, кото��ый вместо сравнения на эквивалентность сравнивает на идентичность. Все 260 созданных в программе объектов RobustCheck не являются идентичными, т.к. физически являются отдельными объектами, размещенными в своих собственных областях памяти. Поэтому методы HashSet "считают" их неравными друг другу и добавляют во множество. В то время как логически неравных объектов RobustCheck только 26 штук, все последующие эквивалентны одному из этих 26-ти. Поэтому нам же необходимо перекрыть (overriding) метод Object#equals, чтобы изменить семантику сравнения. Для этого сигнатура метода RobustCheck#equals должна соответствовать сигнатуре перекрываемого Object#equals; перепишем метод так:

public boolean equals (Object b) {
    if (b instanceof RobustCheck)
        return this.first == ((RobustCheck)b).first && this.second == ((RobustCheck)b).second;
    else
        return false;
}

Чтобы такие ошибки (когда вместо перекрытия мы по ошибке используем перегрузку) смог заметить компилятор, сообщим ему наши намерения о том, что метод Object#equals мы перекрываем в производном классе RobustCheck, добавив соответствующую аннотацию:

@Override
public boolean equals (Object b) {
    if (b instanceof RobustCheck)
        return this.first == ((RobustCheck)b).first && this.second == ((RobustCheck)b).second;
    else
        return false;
}

Ну вот теперь все должно работать как надо:

>java RobustCheck
26

К сожалению, это не исправляет недостатки в дизайне Java. Более интересный вопрос, в дополнение к этой задачке, заключается в том, как вообще избежать всей этой "мумба-юмбы" при определении семантики сравнения двух объектов? В случае с Java ответа, к сожалению, нет. Но можно использовать более продуманные языки. К примеру, Scala, которая самостоятельно определяет корректную семантику сравнения на эквивалентность для неизменяемых (immutable) объектов, избавляя программиста от этой чреватой ошибками задачи:

object Main extends App {
    // Неизменяемые объекты моделируются в Scala с помощью специальных
    // "case"-классов.
    case class RobustCheck(first: Char, second: Char)

    val s = collection.mutable.HashSet.empty[RobustCheck]

    for (i <- 1 to 10)
        for (c <- 'a' to 'z')
            s += RobustCheck(c, c)

    println(s.size)
}

Результат ожидаем:

>scala Main
26

Без всяких заморочек.

Answer 2

Занятно. Правильный ответ подразумевает изменение типа параметра и добавление собачки? :)

UPD. Ах да, еще каст дополнительно будет нужен.

--- spoiler alert ---

В общем, результат в 26 предполагается из-за того, что Set должен содержать только уникальные значения. Для этого переопределяется метод equals(), который, по задумке, должен был бы возвращать true для объектов, у которых одинаковые поля first и second. Фишка же в том, что equals() на самом деле не переопределен - оригинальная сигнатура выглядит как equals(Object o) (1). А Object#equals() выдает true только для идентичных объектов (this == obj) - вот и выходит 260. И программист заметил бы это, если бы использовал аннотацию @Override перед своим методом equals() (2).

P.S. Подобные маневры становятся особенно хорошо заметны, когда готовишься к сдаче SCJP :)

Answer 3

Метод equals не переопределяет Object.equals(Object obj).

Ответы:

1. При одинаковых хэшкодах для каждого 10-ка инстансов имеем разные результаты вызова equals(Object obj), поэтому с точки зрения HashSet мы имеем неэквивалентные инстансы. (в equals(RobustCheck b) мы не попадаем).
2. Аннториуем метод equals c помощью @Override.

Answer 4

Никогда не любил такие задачки, не умею думать =( Но тут вроде бы очевидно: 260, потому что:

26 букв х 10 раз = будет 260

Не хватает ошибок?))