On Oct 18, 1:02 am, Reinier Zwitserloot <[email protected]> wrote:
> Reviewed my copy of Effective Java and you're right, but if you read
> all of chapter 3, you'll find a variety of references to the broken-
> ness of this pattern. Its a mystery to me as to why v2 doesn't mention
> getClass() != other.getClass() anywhere, but none of that changes the
Well, actually it does mention getClass() != other.getClass():
\begin{citation}
// Broken - violates Liskov substitution principle (page 40)
@Override public boolean equals(Object o) {
if (o == null || o.getClass() != getClass())
return false;
Point p = (Point) o;
return p.x == x && p.y == y;
}
\end{citation}
So not only does Bloch not recommend getClass, he thinks it is broken.
The trouble with getClass is that it does not play nice with type
subsumption ~ Liskov principle.
> simple fact that using instanceof without then also making 'equals'
> final is a code bug.
I agree that this is playing with fire and only makes sense if a
subclass has the possibility of making a faster equals()-method. In a
Point2D class hierarchy you could have an abstract class with an
equals method that uses Cartesian coordinates. A PolarPoint2D subclass
that uses polar coordinates could optimise its equal methods in the
case where it is compared to another PolarPoint2D class (no conversion
from polar coordinates to Cartesian coordinates).
Kind regards,
Jacob Grydholt
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
