Java.Core.If equals() is overridden, are there any other methods that should be overridden?

Yes! If you override equals(), you must override hashCode() and should consider overriding toString() and compareTo() (if implementing Comparable).

---

1. hashCode() – Must Be Overridden

📌 Why?

• The contract between equals() and hashCode() states that if two objects are equal (equals() returns true), they must have the same hash code.
• Hash-based collections like HashMap, HashSet, and HashTable rely on hashCode() for efficient storage and retrieval.

Example: Correct Overriding of equals() and hashCode()

import java.util.Objects;

class Person {
    private String name;
    private int age;

    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj) return true;
        if (obj == null || getClass() != obj.getClass()) return false;
        Person person = (Person) obj;
        return age == person.age && Objects.equals(name, person.name);
    }

    @Override
    public int hashCode() {
        return Objects.hash(name, age); // Ensures consistency with equals()
    }
}

🔹 What happens if hashCode() is not overridden?

• Objects that are equal (equals() == true) may get different hash codes, leading to unexpected behavior in hash-based collections.

---

2. toString() – Should Be Overridden

📌 Why?

• toString() provides a human-readable representation of an object, useful for debugging and logging.
• The default implementation (Object.toString()) returns something like Person@1a2b3c, which is not useful.

Example: Overriding toString()

@Override
public String toString() {
    return "Person{name='" + name + "', age=" + age + "}";
}

🔹 What happens if toString() is not overridden?

• You’ll get the default implementation, which is not useful for debugging.

Example Usage:

Person p = new Person("Alice", 30);
System.out.println(p); 
// Before overriding: Person@5e91993f
// After overriding: Person{name='Alice', age=30}

3. compareTo() – Should Be Overridden If Objects Are Comparable

📌 Why?

• If a class implements Comparable<T>, it should override compareTo() to define a natural ordering.
• Used in sorted collections like TreeSet and TreeMap.

Example: Implementing Comparable

class Person implements Comparable<Person> {
    private String name;
    private int age;

    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }

    @Override
    public int compareTo(Person other) {
        return Integer.compare(this.age, other.age); // Sort by age
    }
}

🔹 What happens if compareTo() is not overridden?

• The class won’t be naturally sortable using Collections.sort() or sorted sets/maps.

Example Usage:

List<Person> people = new ArrayList<>();
people.add(new Person("Alice", 30));
people.add(new Person("Bob", 25));

Collections.sort(people); // Sorts by age because of compareTo()

📌 Summary Table

Method	Required?	Why Override?
equals()	✅ Yes	Defines logical equality
hashCode()	✅ Yes	Ensures hash-based collections (like HashSet) work correctly
toString()	✅ Recommended	Improves debugging and logging
compareTo()	✅ If Comparable	Enables sorting in TreeSet, TreeMap, and Collections.sort()

🔹 Final Best Practices

✔ Always override hashCode() when overriding equals().
✔ Override toString() for better debugging.
✔ If sorting is needed, implement Comparable and override compareTo().

By following these rules, your class will work correctly in Java collections and be easier to debug! 🚀