Prev: Call for Papers: International Conference on Internet and Multimedia Technologies ICIMT 2010
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 |