К равняется и хэш-код или не на классах объекта, который является вопросом
Я пытался рассуждать о лучшем способе обработать, является ли это обычно хорошей практикой для реализации хэш-кода и равняется на объектах (я имею в виду объект в общем смысле, но в большинстве случаев это будет объект JPA).
В Главе 24 Быть в спящем режиме ручного http://docs.jboss.org/hibernate/core/3.3/reference/en/html/best-practices.html это говорит это...
Определите естественные ключи для всех объектов и отобразите их использование. Реализация равняется () и хэш-код () для сравнения свойств, которые составляют естественный ключ.
Имеет смысл иметь .equals, и .hashcode включают только эти естественные ключи, но что, если у Вас есть больше чем один экземпляр того же объекта (тот же естественный идентификатор таким образом тот же хэш-код)? Кажется, что эта практика могла иметь тонкие последствия в другом месте в Вашем приложении. Кто-либо попробовал это прежде в крупном масштабе?
2 ответа
Бывают случаи, когда вы хотите, чтобы Equals сравнивал все свойства, и времена, когда вы хотите, чтобы Equals был только ключом. Мы добились гораздо большего успеха, используя явные вспомогательные классы, поэтому нет двусмысленности в том, что сравнивается.
ByKeyComparer.Equals...
ByPropertiesComparer.Equals...
или
Entity1.EqualsByKey...
Entity1.EqualsByProperties...
Я пробовал это раньше в больших масштабах (или по крайней мере, в приложении, которое активно использует спящий режим). Это хорошая идея.
Имеет смысл, чтобы .equals и .hashcode включали только эти естественные ключи, но что, если у вас есть более одного экземпляра одной и той же сущности (один и тот же естественный идентификатор, такой же хэш-код)? Кажется, что эта практика может иметь тонкие последствия в другом месте вашего приложения.
Это то, для чего она предназначена. Обычно требуется, чтобы несколько экземпляров одной и той же сущности преуспели при сравнении .equals, и да, это имеет значение в другом месте. ИМО подразумевает, что все будет работать, как ожидалось.