Is using the instanceof
keyword against the essence of object oriented programming
?
I mean is it a bad programming practice?
I read somewhere that us
Generally speaking yes. It's best to keep all code that depends on being a specific class within that class, and using instanceof
generally means that you've put some code outside that class.
Look at this very simple example:
public class Animal
{
}
public class Dog extends Animal
{
}
public class Cat extends Animal
{
}
public class SomeOtherClass
{
public abstract String speak(Animal a)
{
String word = "";
if (a instanceof Dog)
{
word = "woof";
}
else if (a instanceof Cat)
{
word = "miaow";
}
return word;
}
}
Ideally, we'd like all of the behaviour that's specific to dogs to be contained in the Dog class, rather than spread around our program. We can change that by rewriting our program like this:
public abstract class Animal
{
public String speak();
}
public class Dog extends Animal
{
public String speak()
{
return "woof";
}
}
public class Cat extends Animal
{
public String speak()
{
return "miaow";
}
}
public class SomeOtherClass
{
public String speak(Animal a)
{
return a.speak();
}
}
We've specified that an Animal
has to have a speak
method. Now SomeOtherClass
doesn't need to know the particular details of each type of animal - it can hand that off to the subclass of Animal
.
Favor polymorphism and dynamic binding to downcasting and instanceof
. This is the "OO Way" and enables you to write code that doesn't need to know about subtypes.
EXAMPLE
abstract class Animal {
public abstract void talk();
//...
}
class Dog extends Animal {
public void talk() {
System.out.println("Woof!");
}
//...
}
class Cat extends Animal {
public void talk() {
System.out.println("Meow!");
}
//...
}
class Hippopotamus extends Animal {
public void talk() {
System.out.println("Roar!");
}
//...
}
class Main {
public static void main(String[] args) {
makeItTalk(new Cat());
makeItTalk(new Dog());
makeItTalk(new Hippopotamus());
}
public static void makeItTalk(Animal animal) {
animal.talk();
}
}
How about in the case of a creation factory (See below)? In this case, I don't think it is appropriate for an Animal subclass to know how to build a cage for itself. It seems out of out of scope of what an Animal is and forces the Animal subclass to take on behaviors that are not intrinsic to what an Animal is.
public static Cage createCage(Animal animal) {
if (animal instanceof Dog)
return new DogHouse();
else if (animal instanceof Lion)
return new SteelCage();
else if (animal instanceof Chicken)
return new ChickenWiredCage();
else if (animal instanceof AlienPreditor)
return new ForceFieldCage();
...
else
return new GenericCage();
}
Usage of instanceof
is discouraged when same effect can be achieved via virtual methods, like in example of thomson_matt.
However, it's necessary to use instanceof
in some circumstances. For example, when your code gets Object from external source, say, network or third-party API which returns Object
, and you must decide what is the type of this Object and act appropriately.
The key is to not see instanceof as being part of common "normal practice". Like introspection in general, instanceof is a special tool for use in particular, atypical circumstances. Whenever you do use 'instanceof', you may also find yourself using other 'special' parts of the platform such as reflection more generally.
So long as whenever you find yourself using it you accept that what you're doing is a kludge in the absence of a more elegant/practical alternative, then that's fine.
That said, the most typical circumstances in everyday programs are probably:
A rule of thumb you could try and stick to is to not require users of a library to have to use 'instanceof', but rather have any cases of 'instanceof' internal to the library.
Or put another way, you should re-frame your question: "What are the cases that 'intsanceof' is a workaround for?"
Another usage of instaceOf operation could be error handling. If you have similar error handling for exceptions, and you want to have it all in one place you can use:
public void handleError(Throwable t, HttpServletRequest req) {
if (t instaceOf ValidationException) {
...doSomewthing......
} else if (t instaceOf DataException) {
...doSomewthing......
} else if (t instaceOf DataException) {
...doSomewthing......
} else {
...doSomewthing......
}
}
with above code, you avoid to have many
} catch <Exception> {
blocks and instead have just one
} catch (Throwable t) {
handleError(t, request);
return "errorPage" or whateveryouwant;
}
Also, one more thing is, is you check java source code, you will find so many usages of instaceof..
And one good link: article about usage of instaceof