Re: How to check if object is an instanceof a class, but not a
sub-class ?
Simon Brooke <stillyet+nntp@googlemail.com> wrote:
On Thu, 24 Jun 2010 12:45:02 +0000, Andreas Leitgeb wrote:
Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
On 6/23/2010 5:27 PM, Daniel Pitts wrote:
[... using getClass() in equals() ...] Actually, I would use:
if (other == this) { return true; }
if (other == null || other.getClass() != getClass() { return false; }
Hmm. I usually write
if (other == null || other.getClass() != Thing.class)
Is there a reason to prefer one or the other?
I'm rather surprised to see .equals() being called an exceptional
usecase for exact class-check.
From previous discussions here and elsewhere, I had gathered, that
the "really correct" way to handle (non-trivial!) .equals() in a class
hierarchy would be to make all non-leaf-classes abstract.
Making all non-leaf classes abstract is an example of poor design.
Maybe, you just missed one constraint that I mentioned: My comment
about abstract non-leaf-classes was constrained to hierarchies, that
define their custom .equals() in a way that seems to require exact
class-check. (My previous statement was in itself more general but
it was in the context of needing direct class-check, so it was still
correct in the given context)
It would indeed make no sense at all, to apply my comment generally
to all hierarchies.
[Bird, Penguin extends Bird - should Bird be abstract?]
Actually, you won't ever find a real instance of Bird in nature that
isn't really of some more specific class. Be it Hawk, Craw, Ostrich,
Turkey, Chicken, ...
Are you saying that class Bird ought not to be instantiable?
If (AND ONLY if) you were to define some *finer* equality for
Penguin than you did for Bird, then my claim applies.
More precisely, equal and inheritence work well, as long as the
subclass's .equal() is "equal or coarser" than the superclass's.
Everything is "equal or coarser" than Object's .equals().
The opposite of coarser happens with classes like (partially pseudocode)
class Circle { int radius; ... equals(o) { radius==o.radius;} }
class ColoredCircle extends Circle
{ int color; ... equals(o) { super.equals(o) && color==o.color;} }
ColoredCircle's .equals() is now finer than Circle's.
That's where problems creep in. To solve them, either you resort
to reflection by checking exact class (imho: bad design), or you
make sure, that no direct Circle-instances can exist, and instead
define an "UncoloredCircle" as a separate leaf-class.