Prev: JFileChooser applet doesn't work on all platforms
Next: Is there a 'Filter' or 'Predicate' interface anywhere in theJDK?
From: laredotornado on 23 Jun 2010 13:03
Hi,

I'm using Java 1.6. If I have a object of class "A", I can use the
"instanceof" operator to confirm that the object is of this class.
But if I have an object of class B (extends A), instanceof will also
return true if use "obj instanceof A".

My question is, how can I tell if an object is a direct instantiation
of a class A and not a sub-class of the class A?

Thanks, - Dave
From: Mike Schilling on 23 Jun 2010 13:06


"laredotornado" <laredotornado(a)zipmail.com> wrote in message
news:b9605e9c-42f7-4ba4-a1e9-ee65ba0c539a(a)x21g2000yqa.googlegroups.com...
> Hi,
>
> I'm using Java 1.6. If I have a object of class "A", I can use the
> "instanceof" operator to confirm that the object is of this class.
> But if I have an object of class B (extends A), instanceof will also
> return true if use "obj instanceof A".
>
> My question is, how can I tell if an object is a direct instantiation
> of a class A and not a sub-class of the class A?

Having to know this is probably an indication of poor design. But if you
really need to, try

if (a.getClass() == A.class)

From: Lew on 23 Jun 2010 15:43
laredotornado wrote:
>>> My question is, how can I tell if an object is a direct instantiation
>>> of a class A and not a sub-class of the class A?
>

Mike Schilling wrote:
>> Having to know this is probably an indication of poor design. But if you
>> really need to, try
>>
>> if (a.getClass() == A.class)
>

Daniel Pitts wrote:
> There is one use-case I can think of, and that is properly handling the
> "equals" contract.
>

In that context the idiom is often

if ( other.getClass() != getClass() )
{
return false;
}
...

--
Lew
From: Andreas Leitgeb on 24 Jun 2010 08:45
Eric Sosman <esosman(a)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.

From: Simon Brooke on 25 Jun 2010 04:07
On Thu, 24 Jun 2010 12:45:02 +0000, Andreas Leitgeb wrote:

> Eric Sosman <esosman(a)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.

public class Bird {
public boolean getCanFly() {
return true;
}
}

public class Penguin extends Bird {
public boolean getCanFly() {
return false;
}
}

Are you saying that class Bird ought not to be instantiable? Are you
saying I ought to add a class:

public class InstantiableBird extends Bird {} ?

which has no new semantic content, which overrides or specialises
nothing, and that's 'really correct'?

--

;; Semper in faecibus sumus, sole profundam variat

 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: JFileChooser applet doesn't work on all platforms
Next: Is there a 'Filter' or 'Predicate' interface anywhere in theJDK?