Justified `instanceof`? Using it with an interface but not an implementation type

Question

When a code contains the Java instanceof operator, many people will raise their eyebrows and say it is a no-no. For example, in this other SO Q&A, the answer said:

Note that if you have to use that operator very often it is generally a hint that your design has some flaws. So in a well designed application you should have to use that operator as little as possible (of course there are exceptions to that general rule).

However, it does not further elaborate when the use of instanceof is okay, and when it is not.

I put some thinking on this, and articlate the following guideline. I thought this may have been discussed somewhere on the Internet, but I could not find it. Hence this question and asking for your comment:

Using instanceof on an interface is okay; using instanceof on an implementation is not okay

Here is an example on the "okay" case.

Example: A catalog of animals, some (but not all) of them can fly

Animal.java

public interface Animal {
    String getName();
    String makeNoise();
}

CanFly.java

public interface CanFly {
    float getMaxInAirDistanceKm();
}

Cat.java

public class Cat implements Animal {
    @Override
    public String getName() {
        return "Cat";
    }

    @Override
    public String makeNoise() {
        return "meow";
    }
}

BaldEgale.java

public class BaldEagle implements Animal, CanFly {
    @Override
    public String getName() {
        return "BaldEagle";
    }

    @Override
    public String makeNoise() {
        return "whistle";
    }

    @Override
    public float getMaxInAirDistanceKm() {
        return 50;
    }
}

Catalog.java

import java.util.ArrayList;
import java.util.List;

public class Catalog {
    private List<Animal> animals = new ArrayList<>();

    public void putAnimal(Animal animal) {
        animals.add(animal);
    }

    public void showList() {
        animals.forEach(animal -> {
            StringBuilder sb = new StringBuilder();
            sb.append(animal.getName() + ": ");
            sb.append(animal.makeNoise() + " ");

            // this block exemplifies some processing that is 
            //   specific to CanFly animals
            if (animal instanceof CanFly) {
                sb.append(String.format(" (can stay in air for %s km)",
                        ((CanFly) animal).getMaxInAirDistanceKm()));
            }
            System.out.println(sb.toString());
        });
    }

    public static void main(String[] args){

        Catalog catalog = new Catalog();
        Cat cat = new Cat();
        BaldEagle baldEagle = new BaldEagle();
        catalog.putAnimal(cat);
        catalog.putAnimal(baldEagle);

        catalog.showList();
    }
}

Test Output

Cat: meow 
BaldEagle: whistle  (can stay in air for 50.0 km)

Updated 2019-10-09 Adding example for the "not-okay" case:

We could have dropped the CanFly interface, and in the showList() method, we apply the instanceof on the concrete implementation BaldEagle -- like this:

    public void showList() {
        animals.forEach(animal -> {
            StringBuilder sb = new StringBuilder();
            sb.append(animal.getName() + ": ");
            sb.append(animal.makeNoise() + " ");

            if (animal instanceof BaldEagle) {
                sb.append(String.format(" (can stay in air for %s km)",
                        ((BaldEagle) animal).getMaxInAirDistanceKm()));
            }
            System.out.println(sb.toString());
        });
    }

This approach is not okay because the code is now dependent on implementation, not interface. It prevents, for example, swapping out another implementation representing Bald Eagle (e.g. BaldEagleImpl)

Answer 1

I think people assume that's there is always a "cleaner" solution to produce the kind of behavior you want.

In your example, I would say that the use of Visitor design pattern do exactly the same without the using of instanceOf :

public interface Animal {
    String getName();
    String makeNoise();
    void accept(AnimalVisitor v);
}

public interface AnimalVisitor() {
    void visit(Cat a);
    void visit(BaldEagle a);
}

public interface CanFly {
    float getMaxInAirDistanceKm();
}

public class Cat implements Animal {
    void accept(Visitor v) {
        v.visit(this);
    }
}

public class BaldEagle implements Animal, CanFly {
    void accept(Visitor v) {
        v.visit(this);
    }
}

public class DisplayVisitor implements AnimalVisitor  {
    void visit(Cat a) {
       //build & display your string
    }

    void visit(BaldEagle a) {
       //build & display your string
    }
}

public class Catalog {
    private List<Animal> animals = new ArrayList<>();

    public void putAnimal(Animal animal) {
        animals.add(animal);
    }

    public void showList() {
        DisplayVisitor display = new DisplayVisitor();
        animals.forEach(a->a.accept(display));
    }
}

Although I do not answer completely to your question, it shows that the same behavior can be accomplished without the use of instanceOf in most of cases, just by thinking in OOP way and using known patterns.

Answer 2

However, it does not further elaborate when the use of instanceof is okay

This is not a direct answer to your question, but I'd say that instanceof is only appropriate when all other options aren't feasible.

Using instanceof on an interface is okay; using instanceof on an implementation is not okay

I would re-phrase that as "using instanceof on an interface is less bad than using instanceof on an implementation", but that's just a corollary of the general rule that strong coupling is bad. There are usually better alternatives.

When you want to use instanceof, you should think about introducing additional interfaces or interface methods or using the visitor pattern (see other answer) first. All of these options are cleaner ways to achieve the desired behavior in Java.

This isn't always elegant and can require artificial interfaces or cause interface bloat, which is why some other languages support ad-hoc union types and algebraic data types. But instanceof is not a good way of emulating either, since Java's type system won't help you make sure that you're handling all possible options.

Answer 3

To start out, it's important to note that the Object-Oriented Programming paradigm is the source of resistance to type checking such as instanceof. Other paradigms do not necessarily share this resistance, and may even encourage type checking. So this question is really only relevant if you're trying to do OOP.

If you are trying to do OOP, then you should be leveraging polymorphism as much as you can. Polymorphism is OOP's primary weapon. Type checking is the antithesis of polymorphism.

Certainly type checking of abstractions is preferable to type checking of concrete implementations; but that's just restating the Dependency Inversion Principle (depend on abstractions, not concretions).

In OOP, every usage of type checking can be viewed as a missed opportunity for polymorphism.