如何强制Java接口的实现类重写equals()方法？

Great question! The problem you're facing is a common quirk in Java: since Object already defines equals() and hashCode(), declaring these methods in your interface won't force implementing classes to override them—they’ll just inherit the default Object behavior, which leads to duplicate entries in your Set.

Here are practical solutions to enforce the override, tailored to different design needs:

1. Replace the Interface with an Abstract Class (Most Direct Compile-Time Enforcement) #

If you don’t need your ModuleFactory to be an interface (e.g., you don’t require multiple inheritance), converting it to an abstract class is the cleanest way to force subclasses to implement equals() and hashCode(). By marking these methods as abstract, you override the concrete Object implementations and require all subclasses to provide their own:

public abstract class ModuleFactory<T extends Module> {
    public abstract T createModule(long seed);
    
    @Override
    public abstract boolean equals(Object obj);
    
    @Override
    public abstract int hashCode();
}

Now any subclass that doesn’t implement these three methods will fail to compile—exactly the enforcement you need.

2. Use Default Methods in the Interface (Runtime Enforcement) #

If you must keep ModuleFactory as an interface (for flexibility with multiple inheritance), you can use Java 8+ default methods to throw an exception if the methods aren’t overridden. This way, even though compilation won’t fail, any attempt to use equals() or hashCode() on an unimplemented instance will throw an error, forcing developers to override them:

public interface ModuleFactory<T extends Module> {
    T createModule(long seed);

    @Override
    default boolean equals(Object obj) {
        throw new UnsupportedOperationException("You must override equals() for ModuleFactory implementations");
    }

    @Override
    default int hashCode() {
        throw new UnsupportedOperationException("You must override hashCode() for ModuleFactory implementations");
    }
}

Since Set relies on equals() to check for duplicates, trying to add an unimplemented factory to a Set will immediately throw an exception, making it impossible to ignore the requirement.

3. Enforce via Documentation + Static Code Analysis (Convention + Tooling) #

If you want to keep the interface and avoid runtime exceptions, you can formalize the requirement in your interface’s Javadoc and use static code analysis tools to enforce it. This works well for teams that use tools like Checkstyle, SonarQube, or IntelliJ IDEA’s built-in inspections.

First, update your interface’s documentation to make the requirement explicit:

/**
 * A factory for creating {@link Module} instances.
 * <p>
 * <strong>CRITICAL:</strong> All implementing classes must override {@link Object#equals(Object)}
 * and {@link Object#hashCode()} to ensure correct behavior when stored in collections like {@link java.util.Set}.
 * Use the {@link Override} annotation to confirm the override.
 */
public interface ModuleFactory<T extends Module> {
    T createModule(long seed);
}

Then, configure your static analysis tool to check that all classes implementing ModuleFactory have explicit overrides of equals() and hashCode(). For example, in Checkstyle, you can use the OverriddenEqualsHashCode rule to enforce this.

4. Interface + Abstract Base Class Hybrid (Flexible Middle Ground) #

If you want to retain the interface for polymorphism but still provide a way to enforce the override for most implementations, create a marker interface and an abstract base class that implements it with abstract equals() and hashCode():

// Keep the interface for polymorphism
public interface ModuleFactory<T extends Module> {
    T createModule(long seed);
}

// Abstract base class enforces equals/hashCode override
public abstract class AbstractModuleFactory<T extends Module> implements ModuleFactory<T> {
    @Override
    public abstract boolean equals(Object obj);
    
    @Override
    public abstract int hashCode();
}

Now, most implementations can extend AbstractModuleFactory (and be forced to override the methods), while rare cases can implement ModuleFactory directly—with the understanding that they must follow the documentation and pass static analysis checks.

内容的提问来源于stack exchange，提问作者James