Edward Winchester wrote:I understand hashCode() is a requiremnt if using HashMap, etc.
Edward wrote:I'm just curious how many Java developers reading this go to the trouble of overriding and maintaining these methods?
Pat Farrell wrote:
Its actually more subtle than you suggest. And, there are default equals() and hashCode() funcitons inherited from Object, so you don't have to do anything to use a HashSet/HashMap.
Campbell Ritchie wrote:I shall take Mike Simmons' hint about "beginning"; I think this thread would sit better in "Java in General".
Edward Winchester wrote:I'm really glad I following the link to Pojomatic. [...] Fantastic!.
Edward Winchester wrote:Most of the time I will want to be doing the equality test on all attributes. For the test case I don't. I can't help feeling that I'm missing an elegant trick.
Mike Simmons wrote:I don't know if it's really elegant, but what I've done in the past in this situation is something like:
This can get tedious if there are many fields you want to ignore, but for just one or two, it's fine. It's can also be a bit destructive of the data - you need to be sure that you don't need the value of personO.getId() for anything else before you reset it. In this case, I'm pretty sure you don't (it's just null after all) but in some cases you might.
Mike Simmons wrote:Another technique you can use here is to write custom assertEquals() methods for your classes. If a Foo object has a complex hierarchy attached to it that you want to navigate, you can create
You still may have to write a bunch of tedious stuff, and it might require updating whenever the Foo class or its associated hierarchy changes - but at least you can write that stuff once, and reuse it in your tests whenever you want to test if two Foos are equal. This can often make your tests a lot more readable too.