I guess search in PDF is broken.
The equals contract, nor any other, stipulate that you need to adhere
to Liskov. They do, however, stipulate the transitive, reflexive,
symmetric rule. The suggested equals implementation is broken in that
regard. Josh is a mortal, and therefore fallible. Nevertheless it only
goes to show that the getClass() != other.getClass() style has its
fair share of detractors too.
I guess one could use an annotation or a method (which would have to
be looked up by reflection as well, if the aim is to keep your average
class, which will most likely never be subclassed, free from such
clutter) to let an implementor say: This is merely an optimization.
I've done some more checking and there IS a fatal flaw in my scheme:
Even a .getMethod() lookup on a public method runs a security check
and can thus result in a SecurityException. No clue why. I guess one
could catch the SecurityException and guess, but that's a very bad
idea as it would mean the behaviour of an equals method is dependent
on whether or not a security manager is preventing reflection.
Damn. Back to the drawing board.
On Oct 18, 7:01 pm, grydholt <grydh...@gmail.com> wrote:
> On Oct 18, 1:02 am, Reinier Zwitserloot <reini...@gmail.com> 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 javapo...@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
