Re: Why this overloading example works this way?

[post re-ordered]

"Gabriel Belingueres" <gaby@ieee.org> wrote in message
news:1165433001.178141.161190@j44g2000cwa.googlegroups.com...


    With this pattern, the equals(Object) method always delegates to the
equals(SomeClass) method. I make the assumption that if the "other class" is
not an instance of "this class", then the two objects are clearly not
equal[*]. If they *are* of the same class, then some further analysis (e.g.
of the fields) needs to be done to ensure they are equal, and so the "real"
work is done in the equals(SomeClass) method.

    The hashcode() method only needs to follow the equals(SomeClass) method,
so there isn't an extra layer of complexity here.


    Actually, because equals(Object) always delegates to equals(SomeClass)
(unless the two objects under comparison are trivially unequal, e.g. by
being of different classes), then the equals(SomeClass) method *will* get
called at the appropriate times. And sometimes, the compiler will, at
compile time, make a call to the equals(SomeClass) method:

SomeClass a = new SomeClass();
SomeClass b = new SomeClass();
Object alsoB = b;

a.equals(b); /*directly calls equals(someClass)*/
a.equals(alsoB); /*indirectly calls equals(someClass)*/


    The problem here is that Comparable forces a total ordering on your
type. In designing an implementation for equals(), you only need to
determine whether two objects are equal or not. In designing an
implementation for Comparable, you need to additionally decide which object
is "greater" than the other object, in the case where they're not equal, and
this concept of greater-than might not always make sense.

    - Oliver

*: Actually, making equals "aware" of class hierarchies is slightly trickier
than that. I wanted to gloss over this in my above example, but here's a
more complete example implementation:

public class SomeClass {
  final int field1;
  final String field2;

  /*Constructors, getters, and hashcode*/

  @Override
  public boolean equals(Object other) {
    if (other instanceof SomeClass) {
      return equals((SomeClass)other);
    }
    return false;
  }

  public boolean equals(SomeClass other) {
    if (!other.getClass().equals(this.getClass())) {
      return other.equals(this);
    }
    if (this.field1 != other.field1) {
      return false;
    }
    if (!this.field2.equals(other.field2)) {
      return false;
    }
    return true;
  }
}

There's an extra 3 lines. When equals(SomeClass) is invoked, we know that
other is an instance of SomeClass. But other might actually be a *subclass*
of SomeClass, with additional fields which may or may not be important in
the equals comparison. If it *is* a subclass of SomeClass, then presumably
the subclass "knows about" SomeClass, and is better informed to make the
judgment of whether they are equal, and can thus override the
equals(SomeClass) method, and probably add an equals(SomeSubClass) method.