Question

I have a class Child that extends Parent.

Parent child = new Child();

if (child instanceof Parent){
    // Do something
}

Does this return true or false, and why?

Answer 1

Yes, it would. And why should it not?

Because child is in fact an instance of Parent. If, you want to perform an operation only for a child you should check

if (child instanceof Child){
}

However you should remember the following statement from Effective C++, by Scott Meyers :

"Anytime you find yourself writing
code of the form "if the object is of
type T1, then do something, but if
it’s of type T2, then do something
else," slap yourself.

which I think applies in this case too. If you want to doSomething based on what type of class the referenced object belongs to, the following code structure should help you with it.

NOTE: I have not compiled it.

class Parent {
    public void doSomething() {
        System.out.println("I am the Parent, and I do as I like");
    }
}
 
class ChildA extends Parent {
    public void doSomething() {
        System.out.println("I am a child named A, but I have my own ways, different from Parent");
    }
}
 
class ChildB extends Parent {
    public void doSomething() {
        System.out.println("I am a child named B, but I have my own ways, different from my Parent and my siblings");
    }
}
 
public class Polymorphism101 {
 
    public static void main(String[] args) {
 
        Parent p = new Parent();
        p.doSomething();
 
        p = new ChildA();
        p.doSomething();
 
        p = new ChildB();
        p.doSomething();
 
    }
 
}

EDIT: A better example

You could be developing a drawing application. An application that draws shapes of any kind. In that case, you should have an abstract type Shape.

For purpose(s) like; drawing all shapes; list all shapes; find a shape or delete a shape, you need to have a list of Shapes. Since the list is of a parent type, it can store any shapes.

The Shape interface/abstract class/virtual class should have an abstract/pure virtual function Draw(). So, in your DrawToDeviceLoop, you just call Draw() for each shape, you never need to check what shape it is.

The Shape interface can have an abstract implementation AbstractShape, which can have shape name or id as data members and GetName, Cleanup and other functions with functionality common to all shapes.

Remember an abstract type cannot be instantiated, so Shape itself cannot be instantiated, as it cannot be drawn either.

EDIT 2: Polymorphism and Exception Handling – user1955934 asked "What about checking for exception class" For exception handling the best practices with respect to polymorphism are:

1. Prefer (to throw) specific exception – For example throw a NumberFormatException instead of IllegalArgumentException
2. Catch the most specific exception first – For example, if you catch an IllegalArgumentException first, you will never reach the catch block that should handle the more specific NumberFormatException because it’s a subclass of the IllegalArgumentException.

So, its principally the same, if an exception needs to be handled differently, a child/specific class should be defined, and the specific exception should be caught (not checked instanceof)

To know more best practices on exception handling. See 9 Best practices to handle exception in Java and Best practices for exceptions (C#)

EDIT 3: I admit to an exception in this rule

So, I am working with a legacy code (written in C++), which has mostly been written about 15 years ago, where they always check for the child class to perform certain actions. I was asked to add some code with the same logic, and I told my manager (he is a Dev too) I cannot do this, pointing to this answer, and then we discussed and accepted to this exception to the rule. In our case, this parent class has had just 2 children since the year 2000, and we do not see any child being added in the near future, with the core code limited for growth, we decided that with no addition to child classes and current number being just 2, it is more efficient to check for type, especially when that is how the code has been written, since ever.

There aren’t many instances of this check too though, the parent implements the complicated functionalities mostly and it exists more for sharing code then specializing/differentiating them.