Respuesta.

En Java, los métodos equals() y hashCode() son extremadamente importantes para el correcto funcionamiento de colecciones como HashMap, HashSet, y otros. Esta cuestión a menudo se pasa por alto por los desarrolladores principiantes, aunque la violación de los contratos de estos métodos puede llevar a errores difíciles de detectar en la lógica de las aplicaciones.

Historia de la cuestión:

En el lenguaje Java, originalmente todas las clases heredan los métodos equals() y hashCode() de la clase Object. Por defecto, equals() compara referencias a objetos (es decir, su ubicación física en la memoria), mientras que hashCode() devuelve un código único para cada objeto. Sin embargo, para las clases de usuario, a menudo es necesario comparar objetos por contenido, y no por referencia.

Problema:

Si los métodos equals() y hashCode() no se sobrescriben o se sobrescriben incorrectamente, los objetos pueden comportarse de manera inesperada en colecciones basadas en hashing. Esto resultará en elementos faltantes, duplicados o errores de búsqueda.

Solución:

Es necesario sobrescribir ambos métodos siempre en conjunto, siguiendo estrictamente el contrato:

Si a.equals(b) == true, entonces a.hashCode() == b.hashCode()
Si a.equals(b) == false, no es obligatorio que los hashCode sean únicos.

Ejemplo de implementación correcta:

public class Person {
    private final String name;
    private final int age;

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

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

    @Override
    public int hashCode() {
        return Objects.hash(name, age);
    }
}

Características clave:

El método equals() debe ser reflexivo, simétrico, transitivo y consistente.
El método hashCode() debe devolver el mismo valor para el objeto cuando los datos son inmutables.
En los métodos sobrescritos deben compararse exactamente los campos significativos.

Preguntas capciosas.

¿Se puede usar solo equals() sin hashCode() en clases que se almacenarán en HashSet?

No. Si has sobrescrito solo equals(), las colecciones basadas en hashing no podrán determinar correctamente la unicidad de los objetos. HashSet primero compara hashCode y luego equals.

¿Es obligatorio usar todos los campos de la clase en equals() y hashCode()?

No. Solo los significativos para la identidad lógica de la clase. Por ejemplo, si un objeto tiene un identificador interno y único, es suficiente con eso.

@Override
public boolean equals(Object o) {
    if (this == o) return true;
    if (o == null || getClass() != o.getClass()) return false;
    User user = (User) o;
    return Objects.equals(id, user.id);
}

¿Se puede basar en un getter en lugar de un campo directo en equals()?

Generalmente sí, si no hay efectos secundarios y el getter es estable. Pero existe el riesgo de que el getter devuelva diferentes valores en diferentes llamadas, lo que haría que el comportamiento sea impredecible.

Errores comunes y anti-patrones

No sobrescribir hashCode() al sobrescribir equals().
Usar campos mutables en los cálculos de hashCode().
Ignorar el contrato entre estos métodos.

Ejemplo de la vida real

Caso negativo

El desarrollador implementa la clase User y solo define el método equals(), olvidando hashCode(). Como resultado, al agregar y buscar objetos en HashSet ocurren duplicados y se "pierden" elementos.

Ventajas:

Código mínimo

Desventajas:

Funcionamiento de la colección dañado
Errores ambiguos y difíciles de rastrear en la aplicación

Caso positivo

El desarrollador implementa ambos métodos estrictamente de acuerdo con el contrato, usando solo id dentro de la lógica de igualdad y hash. Las colecciones se comportan como se espera, la búsqueda y el almacenamiento funcionan correctamente.