使用继承重用toString / equals / hashCode

Question

Does it bad practice inherit class to reuse toString/equals/hashCode (that actually based on reflection and use actual class field for it)? For example:

public abstract class SomeAbstractObject {

private List<Field> collectTransientFields() {
    //
    return Arrays.stream(getClass().getDeclaredFields())
            .filter((f) -> f.getAnnotation(Transient.class) != null)
            .collect(Collectors.toList());
}

@Override
public String toString() {
    return ToStringBuilder.reflectionToString(this, DEFAULT_STYLE);
}


@Override
public boolean equals(Object o) {
    //
    List<String> transients = collectTransientFields().stream()
            .map(Field::getName)
            .collect(Collectors.toList());
    return EqualsBuilder.reflectionEquals(this, o, transients);
}

@Override
public int hashCode() {
    List<String> transients = collectTransientFields().stream()
            .map(Field::getName)
            .collect(Collectors.toList());
    return HashCodeBuilder.reflectionHashCode(this, transients);
}

private List<Field> collectTransientFields() {
    //
    return Arrays.stream(getClass().getDeclaredFields())
            .filter((f) -> f.getAnnotation(Transient.class) != null)
            .collect(Collectors.toList());
}

class A extends SomeAbstractObject
class B extends SomeAbstractObject

I benchmarked this implementation of hashCode and IDE-generated one. IDE-generated 10 000 faster for two-field class.

On the other hand there is even library (jakarta) that provide this reflection functionality.

So I have two question:

1. Is it ok to inherit classes for reuse toString/equals/hashCode functionality
2. Is it ok to use reflection-based implementation of toString/equals/hashCode instead of code-generated or human-written one

Answer 1

Your code as a general implementation for equals and hashCode is in my eyes not a good idea for a couple of reasons:

• Retrieving the fields by reflection is a very costly operations. You yourself already found out that we're talking about a factor of about 10,000
• getDeclaredFields only returns the fields of the "current" class and no fields of a superclass. Your actual implementation of equals and hashCode would produce wrong results in such a case.
• When implementing a class you need to keep in mind that all members of a class that aren't supposed to be involved in an equality-check need to be declared transient . For non-serializable classes this is quite uncommon and is therefor easily forgotten.

I'm not sure why you want such a thing anyway, the five minutes you might save while implementing a new class by not writing a distinguished equals and hashCode method are easily beaten by the time you need to track down a bug that might result from the generic implementation. You have to write a testcase for equals and hashCode anyway, even if its implementation is generic, so I don't see a real benefit here.

Edit, final thought: If you have a problem and you think of solving it by using reflection, thing again. Reflection is a powerful tool but can lead to so many new problems that you should avoid it wherever possible. In other words: Reflection is a very specific hammer for very specific nails. Don't try to use it for other types.

Answer 2

Having the semantically correct equals() and hashCode() implementations for a class is crucial for many parts of the Java library, and it deserves attention to details.

Using reflection for equals() and hashCode() will blindly compare all fields. Although that will be OK for many cases (where your class is just a collection of data), there are exceptions. What about fields like "id", "lastChangedDate", "status" and so on? It's quite plausible to not include them in the comparison.

I prefer to decide for every single class which fields to compare and which not, and I'd recommend against inheriting a default behaviour that can't know anything about my specific class.