toString(), equals(), and hashCode() in an interfa

问题:

So, I have an interface with a bunch of methods that need to be implemented, the method names are irrelevant.

The objects that implement this interface are often put into collections, and also have a special toString() format that I want them to use.

So, I thought it would be convenient to put hashCode(), equals(), and toString() into the interface, to make sure that I remember to override the default method for these. But when I added these methods to the interface, the IDE/Compiler doesn't complain if I don't have those three methods implemented, even though I explicitly put them in the interface.

Why won't this get enforced for me? It complains if I don't implement any of the other methods, but it doesn't enforce those three. What gives? Any clues?

回答1:

All objects in Java inherit from java.lang.Object and Object provides default implementations of those methods.

If your interface contains other methods, Java will complain if you don't implement the interface fully by providing an implementation of those methods. But in the case of equals(), hashCode() and toString() (as well as a few others that you didn't mention) the implementation already exists.

One way you might be able to accomplish what you want is by providing a different method in the interface, say, toPrettyString() or something like that. Then you can call that method instead of the default toString() method.

回答2:

It sounds like you want to force your classes to override the default implementations of those methods. If so, the way to do this is to declare an abstract superclass that has the methods declared as abstract. For example:

public abstract class MyBaseClass implements ... /* existing interface(s) */ {

    public abstract boolean equals(Object other);

    public abstract int hashCode();

    public abstract String toString();
}

Then change your current classes to extend this class.

This approach kind of works, but it is not an ideal solution.

• It can be problematic for an existing class hierarchy.

• It is a bad idea to force classes that implement your existing interface to extend a specific abstract class. For example, you can change parameters in method signatures to use the abstract class rather than the existing interface(s). But the end result is less flexible code. (And people can find ways to subvert this anyway; e.g. by adding their own abstract subclass that "implements" the methods with a super.<method>(...) call!)

• Imposing a particular class hierarchy / implementation pattern is short sighted. You cannot predict whether some future requirement change will mean that your restrictions cause difficulties. (This is why people recommend programming against interfaces rather than specific classes.)

---

Back to your actual question about why your interface doesn't force a class to redeclare those methods:

Why won't this get enforced for me? It complains if I don't implement any of the other methods, but it doesn't enforce those three. What gives? Any clues?

An interface imposes the constraint that a concrete class implementing it has an implementation for each of the methods. However, it doesn't require that the class itself implements those methods. The method implementations can be inherited from a superclass. And in this case, that is what is happening. The methods inherited from java.lang.Object saftisfy the constraint.

JLS 8.1.5 states the following:

"Unless the class being declared is abstract, all the abstract member methods of each direct superinterface must be implemented (§8.4.8.1) either by a declaration in this class or by an existing method declaration inherited from the direct superclass or a direct superinterface, because a class that is not abstract is not permitted to have abstract methods (§8.1.1.1)."

回答3:

All 3 of those methods are defined by java.lang.Object which is (implicitly) extended by all other classes; therefore default implementations for those methods exist and compiler has nothing to complain about.

回答4:

Any class that implements your interface also extends Object. Object defines hashCode, equals, and toString and has default implementations of all three.

What you are trying to achieve is good, but not practicable.

回答5:

There's an implementation for those methods coming all the way from Object.

回答6:

If you want to force overriding of equals() and hashCode(), extend from an abstract superclass, which defines these methods as abstract.

回答7:

Your object already contains implementations of those three methods, because every object inherits those methods from Object, unless they are overridden.

回答8:

Java only cares that the methods are defined somewhere. The interface doesn't force you to redefine the methods in new classes that inherit from the interface for the first time if they're already defined. Since java.lang.Object already implements these methods, your new objects conform to the interface even if they don't override these three methods on their own.

回答9:

Other people have answered your actual question sufficiently. As far as a solution for your particular problem, you might consider creating your own methods (maybe getStringRepresentation, getCustomHashcode, and equalsObject), and have your objects extend a base class whose equals, toString, and hashCode methods call these methods.

This might defeat the purpose of using an interface in the first place, though. This is one of the reasons that some people have suggested that equals, toString, and hashCode should never have been included on the Object class in the first place.

回答10:

Adam gives you the reason why you cannot get away with trying to force equals, hashCode and toString. I would go for the following implementation which touches the solution provided by Adam and Stephan:

public interface Distinct {
    boolean checkEquals(Object other);
    int hash();
}

public interface Stringable {
    String asString();
}

public abstract class DistinctStringableObject {

    @Override
    public final boolean equals(Object other) {
        return checkEquals();
    }

    @Override
    public final int hashCode() {
        return hash();
    }

    @Override
    public final String toString() {
        return asString();
    }
}

Now, any class which requires itself to definitely distinct and represented as a String can extend the DistinctStringableObject which will force implementation of checkEquals, hashCode and toString.

Sample concrete class:

public abstract class MyDistinctStringableObject extends DistinctStringableObject {

    @Override
    public final boolean checkEquals(Object other) {
        ...
    }

    @Override
    public final int hash() {
        ...
    }

    @Override
    public final String asString() {
        ...
    }
}

回答11:

Abstract classes won't work if you have a grandchild since its father already overrided both equals and hashCode methods and then you have your problem all over again.

Try using annotatins and APT (http://docs.oracle.com/javase/1.5.0/docs/guide/apt/GettingStarted.html) to get it done.

回答12:

well if u have declared an interface in which by default all the methods are abstract and u do need to provide the functionality but when u implement it in the subclass, then u provide the implementation right. as you can see that every class is the subclass of one superclass(put simply Object is superclass of all the classes) so if u have a class implementing an interface, u need to provide implementation for the methods. but a thing needs to be remembered here that.

irrespective of, if u didn't declare these methods in the interface, you still had this behavior for the subclass that implemented the interface in the first place.

so if don't declare it, it still will be present and another thing is that since these methods and other methods of Object class are present for all the objects of classes, so there is no need for implementation.