0

Consider this theoretical scenario:

I have a Person class. I will NOT be doing any look-up operations with this object. I will use them in Arrays, List but not Sets and Maps. But I would like to check if two list of person Object are equal or not.

for example:

List<Person> list1 = new ArrayList<>();
List<Person> list2 = new ArrayList<>();

If I want to check if these lists are equal, System.out.println(list1.equals(list2))

I will have to implement equals method in my Person class. Do I still need to implement Hashcode(). I am not hashing my Person objects into buckets (only for this I require Hashcode()) and so I think it may not be necessary

brain storm
  • 30,124
  • 69
  • 225
  • 393
  • Are you sure no one will ever try and add it to a set or Map? How can you be certain? As long as no one does, then you should be fine. – Elliott Frisch Jan 27 '14 at 21:57
  • The contract for `hashCode()` states: "If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.". If you're implementing `equals()` but not `hashCode()`, you're likely breaking that contract. – GriffeyDog Jan 27 '14 at 22:05
  • 1
    @GriffeyDog: Thanks for pointing the contract which I am already aware of. but is breaking the contract, will hamper `equals` in the above scenario. I agree it is the best practice to implement both. but this is a theoretical scenario – brain storm Jan 27 '14 at 22:07

1 Answers1

3

It is a best practice to implement hashCode if you are overriding equals. Even though you may not be using them as keys right now, you might in the future. If you are providing this class to someone else for use, then you can't know how they'll use it.

I'd recommend you override it and make it a habit when you override one to override the other. It'll help you out in the long run.

NG.
  • 22,560
  • 5
  • 55
  • 61
  • sure, I agree it is a good practice. but since this an interview question, I want to know the correct one – brain storm Jan 27 '14 at 22:05
  • 1
    This is a good rule of thumb. Apache provides a `HashCodeBuilder` (http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/builder/HashCodeBuilder.html) that makes write `hashCode` methods easy. They also have an `EqualsBuilder` (http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/builder/EqualsBuilder.html) – Mike B Jan 27 '14 at 22:05
  • "Best practice" is another way of saying, "Don't do anything that would surprise another programmer if you can avoid it." A surprise is a bug waiting to happen. Overriding equals() but not hashCode() (or vice versa) would surprise many programmers. – Solomon Slow Jan 27 '14 at 22:08
  • This - if you don't use your objects in any hashed structures, not overriding hashCode will not cause any problems *now*, but it will be easier to make mistakes in the future. If you don't want to waste time implementing hashCode now, `public int hashCode() {return 0;}` is correct but inefficient. – user253751 Jan 27 '14 at 22:10
  • 2
    If someone asked me this on an interview, I would point out that the cost of writing a `hashCode` -- about 2 seconds with a modern IDE, 10 if you want to clean up the generated code a bit -- is well worth the benefit of avoiding problems down the road. – yshavit Jan 27 '14 at 22:12
  • 1
    This is the correct one. If I went to an interview and got dinged for saying this, there's a good chance I would not want to work on their code. Check out http://stackoverflow.com/questions/27581/overriding-equals-and-hashcode-in-java – NG. Jan 27 '14 at 22:32
  • @NG.: This is not a "best practice". This a requirement. This a contract for the hashCode() method. Since equals() method changed, you MUST ensure that hashCode() works as required in the contract. In particular, hashCode() MUST return the same value for two objects if equals() returns "true" for them. – mentallurg Jan 28 '14 at 00:06
  • @immibis: It's only inefficient if many instances of the type are stored in a hashset. Failure to override hashcode could actually make things monstrously less efficient if it causes a hashset to contain lots of duplicate entries. – supercat Jan 29 '14 at 00:04
  • If you don't override hashCode your hashset probably won't work properly (unless a superclass overrides it). If you override it to always return 0 your hashset will work, but it degrades to a linked list, and most operations are O(n) instead of O(1). – user253751 Jan 29 '14 at 09:19
  • @immibis: It may be worthwhile to note that many hashed collections will work just fine with small numbers of items even with all-one-value hash functions. If a collection contains hundreds of items, a good hash function will make a major difference in performance. If thousands, a huge difference. But if it contains three items, or even twelve, even a hash function which always returns the same number will work decently. – supercat Feb 02 '14 at 08:43