Bifalgorithm post · Computer science one · Importance of javaequals() and javahashCode() Methods

Why are equals() and hashCode() important when searching and using sets?

Why are equals() and hashCode() important when searching and using sets? (Computer science one · Importance of javaequals() and javahashCode() Methods) — "Reca…

Ideas in this flowchart

  • Importance of overriding equals() and hashCode() when searching collections
  • Set and List linear searches use equals() to identify a particular instance
  • Hash-based structures such as HashSet also depend on hashCode()
  • Student instances in a HashSet illustrate these methods
  • Two Student objects have the same member-variable values
  • Without overriding equals() and hashCode(), the Set contains both instances
  • With the methods overridden, the Set retains only the first object
  • equals() returns true for the second instance, so the duplicate is not added
  • Immutability prevents changes that can invalidate Set behavior
  • Students with different IDs are initially distinct and both are added
  • Changing b's ID with setId(1234) makes both objects identical
  • The mutation violates the Set's no-duplicates property
  • This is a consequence of mutable object design, not a failure of Set
Feed/

Why are equals() and hashCode() important when searching and using sets?

No cover

Channel

Computer science one

1 page

"Recall that in Chapter 34 we briefly discussed the importance of overloading the equals() and hashCode() methods of our objects. We reiterate this in the context of searching. Recall that the Set and List collections provide linear search methods that do not require the use of a Comparator. This is because the collections use the object’s equals() to determine when a particular instance has been found. In the case of hash-based data structures such as HashSet, the hashCode() method is also important.\n\nTo illustrate the importance of these methods, consider the following code.\n\n1 Student a = new Student(\"Joe\", \"Smith\", 1234, 3.5);\n\n2 Student b = new Student(\"Joe\", \"Smith\", 1234, 3.5);\n\n3\n\n4 Set<Student> s = new HashSet<Student>();\n\n5 s.add(a);\n\n6 s.add(b);\n\nIf we do not override the equals() and hashCode() methods, at the end of this code snippet, the set will contain both of the Student instances even though they are conceptually the same object (all of their member variables will have the same values). However, if we do override the equals() and hashCode() methods as described in Section 34.5, then the code snippet above would result in the Set only having one object (the first one added). This is because during the attempt to add the second instance, the equals() method would have returned true when compared to the first instance and the duplicate element would not have been added to the Set (as Sets do not allow duplicates).\n\nAlso recall that we saw some of the advantages of immutable objects. Again, we point out another advantage. Suppose that we properly override the equals() and the hashCode() methods in our Student object. Further, suppose that we make our Student class mutable: allowing a user to change the ID via a setter. Consider the following code snippet.\n\n1 Student a = new Student(\"Joe\", \"Smith\", 1234, 3.5);\n\n2 Student b = new Student(\"Joe\", \"Smith\", 5679, 3.5);\n\n3\n\n4 Set<Student> s = new HashSet<Student>();\n\n5 s.add(a);\n\n6 s.add(b);\n\n7 //s now contains both students\n\n8 b.setId(1234);\n\nWhen we instantiate the two Student instances, they are distinct as their IDs are different. So when we add them to the set, their equals() method returns false and they are both added to the Set. However, when we change the ID using the setter on the last line, both objects are now identical, violating the no-duplicates property of the Set. This is not a failing of the Set class, just one of the many consequences of designing mutable objects."

Flowchart preview
👍
0
0 comments0 shares

Sign in to view and post comments.