Question

As I’ve always understood it, the main cases where an instanceof is appropriate are:

1. Implementing Object.equals(Object). So if I were writing a List class, and not extending AbstractList for whatever reason, I would implement equals(o) by first testing o instanceof List, and then comparing elements.
2. A significant (algorithmic?) optimization for a special case that does not change semantics, but only performance. For example, Collections.binarySearch does an instanceof RandomAccess test, and uses a slightly different binary search for RandomAccess and non-RandomAccess lists.

I don’t think instanceof represents a code smell in these two cases. But are there any other cases where it is sensible to use instanceof?

Answer 1

Legacy code or APIs outside of your control are a legitimate use-case for instanceof. (Even then I’d rather write an OO layer over it, but timing sometimes precludes a redesign like that.)

In particular, factories based on external class hierarchies seem a common usage.