Does Java have an "is kind of class" test method

Question

I have a baseclass, Statement, which several other classes inherit from, named IfStatement, WhereStatement, etc... What is the best way to perform a test in an if statement to determine which sort of Statement class an instance is derived from?

Solution 1

if (obj.getClass().isInstance(Statement.class)) {
   doStuffWithStatements((Statement) obj));
}

The nice thing about this technique (as opposed to the "instanceof" keyword) is that you can pass the test-class around as an object. But, yeah, other than that, it's identical to "instanceof".

NOTE: I've deliberately avoided editorializing about whether or not type-instance-checking is the right thing to do. Yeah, in most cases, it's better to use polymorphism. But that's not what the OP asked, and I'm just answering his question.

Solution 2

if(object instanceof WhereStatement) {
   WhereStatement where = (WhereStatement) object;
   doSomething(where);
}

Note that code like this usually means that your base class is missing a polymorphic method. i.e. doSomething() should be a method of Statement, possibly abstract, that is overridden by sub-classes.

Solution 3

The answer to your question is instanceof.

However, keep in mind that if your code needs instanceof, it's a sign that something is not right with your design. There are some cases when instanceof is justified, but they are rather exceptions. Usually, if your subclasses need to behave differently, you have to use polymorphism instead of if()s.

Solution 4

isAssignableFrom(java.lang.Class) from class is your answer.

Solution 5

Try this:

if (Statement.class.isInstance(obj)) {
    doStuffWithStatements((Statement) obj));
}

since Class.isInstance() method takes an object instance as a parameter.

View more solutions

Comments

[Heat Miser]

Thanks for the additional info! I'll look into it to see if there is a clean way to improve the design.

[Steve Kuo]

Why not just use the simpler instanceof check?

[David Taylor]

instanceof is not evil like goto. There is a reason it was added to the language and why it has not been deprecated.

[monksy]

The only thing I would add to your commend is the strong suggestion of programming by interface.

[Viktor Dahl]

+1 for not "editorializing about whether or not type-instance-checking is the right thing to do"

[mikera]

+1 for the answer, though I would add that instanceof has plenty of valid uses - it's not always a design smell. For example, if doSomething() is only ever applicable to where clauses then this pattern is probably better than artificially making doSomething() part of the Statement class (where it doesn't logically fit).

[dwilliss]

Another example of where instanceof is useful. In JavaFX, you have a Pane. I need to traverse the tree of child nodes. getChildren() returns Nodes. But if one of the nodes is a Pane, I need to traverse its children too. Node doesn't have a getChildren() method and isn't mine to add one to. So I have to use node instanceof Pane to see if I need to cast the Node to a Pane and traverse its children.

[geowar]

If only a sub-class can doStuff (™paxdiabio) and you have an array of objects some of which are a super class of the sub-class then this is the better way to do it (rather than add no-op'd doStuff methods to the super-class(es) which may be meaningless (or "just wrong")).

[paxdiablo]

@geowar, if you have a collection of non-homogeneous things, they probably shouldn't be in the collection. Or, at a minimum, you shouldn't be iterating over that collection in a way that wants to doStuff. There are various ways to handle this but tying it to the class name or type can be very problematic when making changes. In the inheritance/OO world, having a null function for the superclass that wants to do nothing for this case is actually quite a valid solution, making the processing code much cleaner.