Ответ.

История вопроса:

Ключевое слово instanceof появилось в Java для проверки, принадлежит ли объект заданному типу или его подтипу. Механизм позволил в рантайме уточнять тип объекта, что важно для работы с обобщёнными коллекциями, полиморфизмом и приведением типов.

Проблема:

Без корректного определения типа объекта возможны ошибки ClassCastException или некорректная обработка логики в ветвях кода, если производить приведение типов без проверки. При этом чрезмерное использование instanceof часто является признаком неудачного проектирования.

Решение:

instanceof возвращает true, если объект является экземпляром данного класса или любого его подкласса, либо реализует интерфейс. В Java 16 был представлен паттерн matching с автоматическим приведением типа в блоке if.

Пример кода:

Object obj = "Hello!";

if (obj instanceof String) {
    String s = (String) obj; // Приведение безопасно
    System.out.println(s.length());
}

С Java 16:

if (obj instanceof String s) {
    System.out.println(s.length()); // s автоматически приводится к String
}

Ключевые особенности:

Работает для классов и интерфейсов
Безопасно возвращает false при null (null instanceof Type всегда false)
Избыточное использование может скрывать ошибки в архитектуре

Вопросы с подвохом.

Что вернет null instanceof SomeClass?

Всегда false. Оператор гарантирует, что если объект null, то результат — false, исключая NullPointerException.

Можно ли использовать instanceof с параметрами дженериков, например if (obj instanceof List<String>)?

Нет. Из-за стирания типов (type erasure) нельзя проверять generic параметры в runtime. Проверка всегда делается только по raw-типу (например, List).

Пример кода:

List<String> list = ...;
if (list instanceof List<String>) { ... } // Ошибка компиляции
if (list instanceof List) { ... } // Разрешено

Может ли использование instanceof указывать на проблемы в дизайне кода?

Да. Постоянное использование instanceof вместо применения абстракций или паттернов (например, паттерн Visitor) часто указывает на нарушение принципов ООП, таких как открытость/закрытость.

Типовые ошибки и анти-паттерны

Приведение типа без проверки через instanceof
Использование instanceof в больших блоках для обработки логики (switch по типам вместо полиморфизма)
Попытка проверки generic-типов через instanceof

Пример из жизни

Негативный кейс

В методе присутствует большая цепочка if-else с проверкой всех возможных подклассов одного суперкласса через instanceof, внутри каждой ветки — приведение типа и вызов соответствующего метода.

Плюсы:

Быстро реализовано для небольшой иерархии классов

Минусы:

Усложнение при добавлении новых подклассов, нарушение SRP, сложно тестировать

Позитивный кейс

Вместо if-else реализован паттерн Visitor: у каждого подкласса есть метод, вызывающий нужное поведение, что избавляет от instanceof.