HalcyonWild said:
I searched google before posting this. Opened the links on the first
few pages. What I found is this:
instanceof is some kind of programmer's duct tape. You should try to
avoid it, and use real nuts and bolts in your code, but if you can't
avoid it you are glad that you have it.
In practice, this means if the design of some new code relies on
instanceof you should better think twice and look for other solutions.
If you have to "somehow" interface to existing code out of your control,
instanceof can be the thing that saves you.
1. There are some pages which say use of instanceof is ok(javaworld
actually says its good to use instanceof before attempting casting),
IMHO you interpreted this in the wrong way. I bet, the javaworld author
said or wanted to say:
If(!) you are about to cast an object of totally unknown type,
it is a good idea to check with instanceof first. This way you
can avoid having to deal with the class cast exception.
This is indeed one of these duct tape things. One is usually unsure of
the real type of an object if it is created by some part (library, etc.)
of the application outside of the own control. So you somehow figure out
the real type, and then you cast to it - but, as a safeguard you better
check.
If you are unsure of the type of an object in your own code, you better
revise your own code, instead of adding safeguards.
and some which say it should be avoided.
I am in that camp.
2. None of them say hardcoding a class name is the reason.
It is one of the things which makes instanceof impractical.
3. One of them even goes on to say avoid casting, in its list of best
practices.
Which is indeed good advice. Unfortunately the standard API and classes
often force you to do some casting. This got better with Java 1.5 where
e.g. the casting needed for the collection classes can be replaced by
using generics.
Still, in your own code avoiding casting is a good idea.
4. A page from MIT said it indicates clumsy structuring. Not very
enlightening.
They are right. It is exactly that. If you feel the need to use an
instanceof in your code, some little alarm bell in your head should ring
and you should investigate your code for a better solution.
One page which I found said that more use of instanceof indicates
poorly designed classes with insufficient use of polymorphism.
Yes, again they are right. Making use of polymorphism is often a better
design alternative to using an instanceof. Using instanceof in fact
often indicates that the programmer didn't get OO programming very well.
What about a scenario where in you want to take different actions on
different subclasses, say SubClass1 and SubClass2, and you are passed
the parent of these two subclasses as parameter in your method.
Bzzzz, game over, you lost.
(1) Instead of
void myMethod(Superclass o) {
if(o instanceof SubclassA) {
// do something specific for SubclassA
} else if(o instanceof SubclassB) {
// do something specific for SubclassB
}
}
you write (2)
void myMethod(SubclassA o) {
// do something specific for SubclassA
}
void myMethod(SubclassB o) {
// do something specific for SubclassB
}
(3) Or, sometimes it makes more sense to implement the particular method
as part of the object itself, overriding a Superclass method:
void myMethod(Superclass o) {
o.doSomething();
}
You
have to check which subclass it is exactly.
No, you leave this to the compiler.
I am using
polymorphism/inheritance here, since I get the parent class.
You use dynamic polymorphism with static type checking. Already the
usage of the two words "dynamic" and "static" in the same sentence
should ring a bell. Using a separate method for each subtype (2) fixes
the problem with ad-hoc polymorphism (overloading). Using overridden
methods and double-dispatch (3) is another possible fix.
Where does the wrong design thing come in.
From your idea that you, yourself absolutely have to check the type of
an object if you need to do some type-specific operation on that object.
/Thomas
