在类中返回 super.equals 和 super.hashcode 是一种不好的做法吗？

Question

Let's say i have this class:

public class Person {
    private Integer idFromDatabase;
    private String name;

    //Getters and setters
}

The field idFromDatabase is the attribute that should be verified in equals and used to create the hashCode. But sometimes, i am working with a list of People in memory, and have not yet stored the objects on the database, so the idFromDatabase is null for all objects, which would cause hashCode to return the same value for every object. I solved this issue by adding the following to equals and hashCode metods:

if(idFromDatabase == null) return super.equals(o);

and

if(idFromDatabase == null) return super.hashCode();

It worked, but is it safe? Can i do it for every class that relies on a database field for equality check?

Answer 1

if(idFromDatabase == null) return super.equals(o); is incorrect as super's equals (if implemented correctly) does a getClass() check, which will of course be different, thus super.equals will always be false.

Answer 2

From your description I'm inferring that when comparing two People objects:

• If both have an ID, they are equal if they have the same ID, even if they have different names
• Otherwise, they are only equal if they are the same instance.

If that's correct, then:

@Override
public boolean equals(Object obj) {
    if (this == obj)
        return true;
    if (this.idFromDatabase == null)
        return false;
    if (! (obj instanceof People))
        return false;
    People that = (People)obj;
    if (that.idFromDatabase == null)
        return false;
    return this.idFromDatabase.equals(that.idFromDatabase);
}
@Override
public int hashCode() {
    // Use super.hashCode to distribute objects without an idFromDatabase
    return (this.idFromDatabase != null ? this.idFromDatabase.hashCode() : super.hashCode());
}

Answer 3

As already noted by @Jeroen Vannevel, if you are likely to end up with having 2 or more objects not stored in database holding the exact same information, then this technique will not help you in identifying this.

@Solver is also quite true in that a subclass is meant to have different behavior than its superclass, so you shouldn't return that they're equal.

However, in your particular example, you are just extending the Object class, so your assumption that it is safe is true (if we exclude the possibility of having 2 not-yet-persisted same Person s in memory).

Object provides the most basic equals method :

For any non-null reference values x and y, this method returns true if and only if x and y refer to the same object ( x == y has the value true ).

The hashCode method of Object:

As much as is reasonably practical, [...] does return distinct integers for distinct objects

These definitions make it clear that if you're only extending Object , then this technique is safe.

Answer 4

There are a few problems with your reasoning.

• equals and hashcode are not subtype-friendly so it doesn't make sense to start thinking about super calls,
• super is Object anyway so it's equals and hashcode are useless in this context.
• What if you have two Person objects referring to the same person, but only one is stored in the database. Are they the same or different?

One universal solution is to make two classes

1. Person which stores a 'local' person. Doesn't contain idFromDatabase ,
2. StoredPerson which contains idFromDatabase and a Person (or all fields of Person , but this is harder to maintain)

This way, at least equals and hashcode are well-defined and well-behaved at all times.

Implementation and usage

If you use any kind of Set / Map to store people, you now have two of them. When you save new Person s to database, you remove them from the 'local' Set / Map , wrap them in StoredPerson , and put them in the 'database' Set / Map .

If you want a searchable list of all people, make one with all Person s from both datasets into one. When you find a Person you're interested in and want to retrieve the idFromDatabase , if any, then you'd do good to prepare a map from Person to StoredPerson beforehand.

Thus you need at least,

Set<Person> localPeople = new HashSet<>();
Map<Person, StoredPerson> storedPeople = new HashMap<>();

and something like this:

void savePerson(Person person) {
    synchronized (lockToPreserveInvariants) {
        int id = db.insert(person);

        StoredPerson sp = new StoredPerson(id, person);

        localPeople.remove(person);
        storedPeople.put(person, sp);
    }
}