Alternatives for instanceof Operator in Java

1. Overview

instanceof is an operator that compares an object’s instance to a type. It’s also called a type comparison operator.
In this tutorial, we’ll look at different alternatives to the traditional instanceof approach. We may need alternatives to improve code design and readability.

2. Example Setup

Let’s develop a simple program, Dinosaur and Species. This program will have a parent class and two child classes, i.e., the child classes will extend the parent class.
First, let’s create the parent class:

public class Dinosaur {
}

Next, let’s create the first child class:

public class Anatotitan extends Dinosaur {
    String run() {
        return "running";
    }
}

Finally, let’s create the second child class:

public class Euraptor extends Dinosaur {	
    String flies() {
        return "flying";
    }
}

The Dinosaur class has other methods common to the subclasses, but we’re skipping them for simplicity.
Next, let’s write a method to create new instances of our objects and invoke their movement. We’ll use instanceof to check our new instance type before returning a result:

public static void moveDinosaur(Dinosaur dinosaur) {
    if (dinosaur instanceof Anatotitan) {
        Anatotitan anatotitan = (Anatotitan) dinosaur;
        anatotitan.run();
    } 
    else if (dinosaur instanceof Euraptor) {
        Euraptor euraptor = (Euraptor) dinosaur;
        euraptor.flies();
    }
}

In the next sections, we’ll apply different alternatives.

3. Using getClass()

The getClass() method helps to get the class of an object. We can use the getClass() as an alternative to instanceof when checking whether an object belongs to a particular class or not.
In our example setup, let’s maintain the structure of our parent class and the subclasses. Then, let’s write a test method for this approach. We’ll use getClass() instead of instanceof:

public static String moveDinosaurUsingGetClass(Dinosaur dinosaur) {
    if (dinosaur.getClass().equals(Anatotitan.class)) {
        Anatotitan anatotitan = (Anatotitan) dinosaur;
        return anatotitan.run();
    } else if (dinosaur.getClass().equals(Euraptor.class)) {
        Euraptor euraptor = (Euraptor) dinosaur;
        return euraptor.flies();
    }
    return "";
}

Let’s proceed to write a unit test for this approach:

@Test
public void givenADinosaurSpecie_whenUsingGetClass_thenGetMovementOfEuraptor() {
    assertEquals("flying", moveDinosaurUsingGetClass(new Euraptor()));
}

This alternative maintains our original domain objects. What changes is the use of getClass().

4. Using Polymorphism

The concept of polymorphism makes a subclass override a method from the parent class. We can use this concept to change our example setup and improve our code design and readability.
Since we know all dinosaur move, we can change our design by introducing a move() method in our parent class:

public class Dinosaur {	
    String move() {
        return "walking";
    } 
}

Next, let’s modify our subclasses by overriding the move() method:

public class Anatotitan extends Dinosaur {
    @Override
    String move() {
        return "running";
    }
}
public class Euraptor extends Dinosaur {
    @Override
    String move() {
        return "flying";
    }
}

Now we can reference the subclasses without using the instanceof approach. Let’s write a method that accepts our parent class as an argument. We’ll return our dinosaur movement based on its specie:

public static String moveDinosaurUsingPolymorphism(Dinosaur dinosaur) { 
    return dinosaur.move(); 
}

Let’s write a unit test for this approach:

@Test 
public void givenADinosaurSpecie_whenUsingPolymorphism_thenGetMovementOfAnatotitan() { 
    assertEquals("running", moveDinosaurUsingPolymorphism(new Anatotitan()));
}

When possible, it’s recommended to change our design itself using this approach. The use of instanceof is often an indication that our design violates the Liskov Substitution Principle (LSP).

5. Using an Enumeration

In enum types, variables can be defined as sets of predefined constants. We can use this approach to improve our simple program.
First, let’s create an enum with constants that have methods. The methods of the constants override an abstract method in the enum:

public enum DinosaurEnum {
    Anatotitan {
        @Override
        public String move() {
            return "running";
        }
    },
    Euraptor {
        @Override
        public String move() {
            return "flying";
        }
    };
    abstract String move();
}

The enum constants act like subclasses used in other alternatives.
Next, let’s modify our moveDinosaur() method to use the enum type:

public static String moveDinosaurUsingEnum(DinosaurEnum dinosaurEnum) {
    return dinosaurEnum.move();
}

Finally, let’s write a unit test for this approach:

@Test
public void givenADinosaurSpecie_whenUsingEnum_thenGetMovementOfEuraptor() {
    assertEquals("flying", moveDinosaurUsingEnum(DinosaurEnum.Euraptor));
}

This design made us eliminate the parent class and the subclasses. This approach is not recommended in a complex scenario where the parent class will have more behavior than our example setup.

6. Using Visitor Pattern

The Visitor pattern helps to operate on similar/related objects. It moves the logic from the object class to another class.
Let’s apply this approach to our example setup. First, let’s create an interface with a method and pass a Visitor as an argument. This will help to retrieve the type of our object:

public interface Dinosaur {
    String move(Visitor visitor);
}

Next, let’s create a Visitor interface with two methods. The methods accepts our subclass as an argument:

public interface Visitor {
    String visit(Anatotitan anatotitan);
    String visit(Euraptor euraptor);
}

Next, let’s make our subclasses implement the Dinosaur interface and override its method. The method has Visitor as an argument to retrieve our object type. This method replaces the use of instanceof:

public class Anatotitan implements Dinosaur {
    public String run() {
        return "running";
    }
    @Override
    public String move(Visitor dinoMove) {
        return dinoMove.visit(this);
    }
}

Next, let’s create a class to implement our Visitor interface and override the methods:

public class DinoVisitorImpl implements Visitor {
    @Override
    public String visit(Anatotitan anatotitan) {
        return anatotitan.run();
    }
    @Override
    public String visit(Euraptor euraptor) {
        return euraptor.flies();
    }
}

Finally, let’s write a test method for this approach:

public static String moveDinosaurUsingVisitorPattern(Dinosaur dinosaur) {
    Visitor visitor = new DinoVisitorImpl();
    return dinosaur.move(visitor);
}

Let’s write a unit test for this approach:

@Test
public void givenADinosaurSpecie_whenUsingVisitorPattern_thenGetMovementOfAnatotitan() {
    assertEquals("running", moveDinosaurUsingVisitorPattern(new Anatotitan()));
}

This approach made use of an interface. The Visitor contains our program logic.

7. Conclusion

In this article, we’ve examined different instanceof alternatives. The instanceof approach potentially violates the Liskov Substitution Principle. Adopting alternatives gave us a better and more solid design. The polymorphism approach is recommended as it adds more value.