Понимание работ равняется и хэш-код в HashMap
Я все еще полагаю, что XSLT может быть полезным, но это - ужасный язык и может привести к ужасной нечитабельной, неудобной в сопровождении путанице. Частично, потому что XML не достаточно человекочитаем для составления "языка" и частично потому что XSLT застревает где-нибудь между тем, чтобы быть декларативным и процедурным. Однако и я думаю, что сравнение может проводиться с регулярными выражениями, оно имеет, это - использование когда дело доходит до простых четко определенных проблем.
Используя альтернативный подход и анализирующий XML в коде может быть одинаково противным, и Вы действительно хотите использовать некоторый XML маршалинг/привязка технологии (такой как JiBX в Java), который преобразует Ваш XML прямо в объект.
4 ответа
I cannot emphasize enough that you should read Chapter 3 in Effective Java (warning: pdf link). In that chapter you will learn everything you need to know about overriding methods in Object, and in particular, about the equals contract. Josh Bloch has a great recipe for overriding the equals method that you should follow. And it will help you understand why you should be using equals and not == in your particular implementation of the equals method.
Hope this helps. PLEASE READ IT. (At least the first couple items... and then you will want to read the rest :-).
-Tom
When hashCode is uncommented, HashMap sees t1 and t2 as being the same thing; thus, t2's value clobbers that of t1. To understand how this works, note that when hashCode returns the same thing for two instances, they end up going to the same HashMap bucket. When you try to insert a second thing into the same bucket (in this case t2 is being inserted when t1 is already present), HashMap scans the bucket for another key that is equals. In your case, t1 and t2 are equals because they have the same day. At that point, "payBills" clobbers "doLaundry". As for whether t2 clobbers t1 as the key, I believe this is undefined; thus, either behavior is allowed.
There are a few important things to think about here:
- Are two ToDos instances really equal just because they have the same day of the week?
- Whenever you implement equals, you should implement hashCode so that any two objects that are equals also have the same hashCode values. This is a fundamental assumption that HashMap makes. This is probably also true of anything else that relies the hashCode method.
- Design your hashCode method so that the hash codes are evenly distributed; otherwise, you won't get the performance benefits of hashing. From this perspective, returning 9 is one of the worst things you can do.
Вы заменили равным без изменения хэш-кода . Вы должны убедиться, что для всех случаев, когда равно возвращает истину для двух объектов, hashCode возвращает одно и то же значение. Хэш-код - это код, который должен быть равен, если два объекта равны (обратное не обязательно). Когда вы вводите жестко запрограммированное значение 9, вы снова удовлетворяете условиям контракта.
В вашей хэш-карте равенство проверяется только в пределах хеш-ведра. Два ваших объекта Monday должны быть равны, но поскольку они возвращают разные хэш-коды, метод equals даже не вызывается для определения их равенства - они помещаются прямо в разные сегменты, и вероятность того, что они равенство даже не считается.
Если вы не переопределяете метод hashCode (), ваш класс ToDos наследует метод hashCode () по умолчанию от Object, который дает каждому объекту отдельный хэш-код. Это означает, что t1 и t2 имеют два разных хэш-кода, даже если вы их сравниваете, они были бы равны. В зависимости от конкретной реализации хэш-карты, карта может хранить их отдельно (и именно это и происходит).
Когда вы правильно переопределяете метод hashCode (), чтобы гарантировать, что равные объекты получают одинаковые хэш-коды, хэш-карта может найти два одинаковых объекта и поместить их в одно и то же хэш-ведро.
Лучшая реализация даст объекты, которые не равны различным хеш-кодам, например:
public int hashCode() {
return (day != null) ? day.hashCode() : 0;
}