Re: Subclasses and the equals method
pek wrote:
Points didn't help me. I don't see why I would compare a Point with a
ColorPoint without knowing that I will have to breaking something. And
I can't think of a good example to perfectly understand his point.
I think this is specifically where you're missing the crucial point.
Look at his examples with ColorPoint. OK, you can see something's going
on, but what?
I think here it is: in *Point* look at the equals method:
@Override
public boolean equals( Object o ) {
if( !(o instanceof Point) ) // <-- THE PROBLEM
return false;
Point p = (Point)o;
return p.x == x && p.y == y;
}
That's what he can't get around. When Point is defined, it doesn't know
what other points might subclass it. In Effective Java you know you
have a ColorPoint, but what about PixelPoint? MeshPoint? FanPoint?
(Names of OpenGL graphics structures in those last two.) Point only
knows about other Points and only compares x and y. That's all it can do.
That's what he's trying to maintain symmetry and transitivity with, and
he can't. That's why he's calling super.equals(), because he's showing
even doing that won't help. ColorPoint *is* a point, "instance of Point"
will be true, and the Point class will compare on x and y only, ignoring
the extra info. The only way around this is to compare ColorPoint on x
and y also, ignoring color, and that's clearly not right (which Bloch
mentions right at the start of that discussion).
Redo the examples in your head, paying close attention to the code above
when the Point class is involved. There's no way to extend the Point
class and still get it's equals method to work right, because when
Point p1 = ... anything
ColorPoint cp1 = ... anything
p1.equals( cp1 );
is invoked, p1 doesn't know to check for a subclass. It can't and can
only compare on x and y.
Inheritance only changes methodology or strategy, I guess. It doesn't
actually create a "subclass" in the everyday meaning of the word. A
ColorPoint is not really a Point, the two are completely different in
the way they work, due to the need to handle the extra field.
To me this says "if you define an equals method, make the class final."
Which is darn similar to what Scott Meyers and Bjarne Stroustrup have
been saying for a while: classes for designed inheritance should be
abstract. Concrete classes should be leaf classes (not inherited from).