Добрый день! Недавно попалась весьма интересная задачка на 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 s = new HashSet() 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()) } } <br>И вопросы: Почему программа возвращает размер 260 вместо 26? Как ее исправить? Чего не хватает в данной программе, чтобы она указала ошибку на этапе компиляции?
Ответ Задача на знание краеугольных камней языка 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)<br> println(s.size) } Результат ожидаем: >scala Main 26 Без всяких заморочек.