Is instanceof bad practice? If so, under what circumstances is this even more preferable?

Question

Over the years, I tried to avoid instanceof whenever possible. Using a polymorphism or visitor pattern, where applicable. I suppose this just makes servicing easier in some situations ... Are there any other disadvantages to be aware of?

I still see it here and there in the Java libraries, so I guess it has its place? Under what circumstances is this preferable? Is it always inevitable?

Answer 1

I can imagine some cases, for example, you have some library objects that you cannot extend (or it would be inconvenient to do this), possibly mixed with some objects of yours, all with the same base class, together in the collection.
I believe that in this case it is useful to use instanceof to distinguish some processing on these objects.

We are going to some maintenance of obsolete code where you cannot introduce some new behavior into many old classes, just adding a new little function or fixing a bug ...

Answer 2

He definitely has his place in the implementation of stock equals . For example.

 public boolean equals ( Object o ) { if ( this == o ) { return true; } if ( ! (o instanceof MyClass) ) { return false; } // Compare fields ... } 

One neat thing to know about instanceof is that its LHS can be null , in which case the expression evaluates to false .

Answer 3

I think that when you absolutely need to know the type of an object, instanceof is the best option.

Bad practice would be to have many instanceof s, one next to each other, and, according to them, call different methods of objects (of course, casting). This will probably reflect on the fact that the hierarchy needs to be rethought and, probably, refactored.

Answer 4

When you are in a pure OO model, then instanceof definitely the smell of code.

If, however, you are not using a 100% OO model or you need to inject material into it from the outside, then instanceof or equivalents ( isXXX() , getType() , ...) can have their own applications.

A general “rule” would be to avoid it whenever possible, especially when you control the type hierarchy and can use, for example, a subtype polytype. The idea is not to ask the object what type it is and to do something with it, but rather directly or indirectly request the object through a visitor (essentially a double polymorphism) to perform some actions.

Answer 5

It can be used as a sanity check before casting; in addition to checking that your object is of the correct type, it also checks that it is not null.

 if (o instanceof MyThing) { ((MyThing) o).doSomething(); // This is now guaranteed to work. } else { // Do something else, but don't crash onto ClassCast- or NullPointerException. } 

Answer 6

I studied the same topic for other purposes, and I found the following links really good.

• Prefer instance polymorphism and downcasting
• instanceof versus getClass in equal methods (Interview with Josh Bloch)
• Polymorphism and interfaces (see "When to use an instance" section)

Answer 7

I agree that this can have an unpleasant odor. Many instances, especially in the chain, if blocked, smell bad.

Sometimes it can behave in a way you did not expect ... Something that I once happened:

 Class B extends A Class C extends A B b = new B(); C c = new C(); b instanceof B -> true b instanceof C -> true c instanceof C -> true c instanceof B -> true 

(in my case, it was due to sleep mode making proxy objects .... but just the case when the dpending code on instanceof is risky)

Answer 8

How about if you create a factory? eg.

 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(); }