Здравствуйте, vsb, Вы писали:

scf>>Это вопрос дизайна языка. equals/hashСode в Object подталкивают программистов к их переопределению в собственных объектах, тем более, что equals почти всегда нужен, а правила соответствия equals/hashСode вдалбливаются начинающим программистам с самого начала изучения языка.

vsb>Не знаю, я вроде не начинающий программист, но меня это никуда не подталкивало никогда. Если реально нужен equals — переопределяю. Если объект в виде ключа в хеш-таблице используется — переопределяю hashCode.

Правила таки о том, что это надо делать одновременно. Если ты переопределил hashCode() => переопредели и equals(), и наоборот.
Иначе с хэш-таблицами таки будут проблемы — например, оно найдёт позицию, куда записать ключ, но не сможет заменить его предыдущую версию.

vsb> Просто так — зачем, это же мёртвый код, а к нему по-хорошему и тесты писать надо и в будущем поддерживать. А вот забыть и использовать вполне можно. Было бы по уму сделано, такой код не скомпилировался бы.

Ну, это всё-таки ещё не для мэйнстрим-языка образца 95-го года.

vsb> По-хорошему должны быть интерфейсы Equatable, Hashable, так же как Comparable и если нужны соотв. методы, реализуешь интерфейс. Либо, что ещё правильней, определять отдельные объекты вроде Equator, Hasher по аналогии с Comparator и передавать их в соотв. структуры данных.

Ну в плюсах есть такая возможность, но по умолчанию они используют таки стандартные сравнения.