Re: Subclasses and the equals method
On Aug 10, 11:42 pm, Mark Space <marksp...@sbc.global.net> wrote:
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 kno=
w
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.
Yes, I understanded that this will not work for subclassed object that
have an equal method. IIs there any example that you can think of
where you would like to compare a class with it's superclass? He
proves that this can't happen and you need a workaround (aspect), but
I can't think of why would you want that in the first place.
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)=
..
I must admit, I really liked this. Will try to follow it from now on.
Nice advise, thank you..