Краткий ответ

Успех приведения определяется фактическим классом объекта, на который указывает ссылка, а не только типом самой ссылки. Во время компиляции Java проверяет, допустимо ли такое приведение в принципе; во время выполнения проверяется, является ли объект экземпляром целевого класса или его подкласса. Если объект несовместим, возникает ClassCastException.

Исторический контекст

Такой механизм сочетает статическую типизацию с полиморфизмом. Переменная может иметь интерфейсный тип и скрывать конкретный класс реализации, но при необходимости программа может явно запросить более конкретный тип.

Исходная проблема состоит в том, чтобы сохранить преимущества общего контракта интерфейса и одновременно разрешить работу со специфичными возможностями конкретной реализации. Цена этого решения — необходимость проверки совместимости во время выполнения для потенциально небезопасного сужающего приведения.

Постановка проблемы

Интерфейсная ссылка не сообщает, какой именно класс создал объект. Поэтому одинаковая по статическому типу ссылка может в одном случае указывать на объект нужного класса, а в другом — на объект совершенно другой реализации.

Ошибочное предположение о фактическом типе приводит к аварийному завершению операции в точке приведения. Это особенно опасно в коде, работающем с плагинами, коллекциями интерфейсных объектов и объектами, созданными внешними библиотеками.

Подробное решение

Компилятор сначала анализирует статические типы. Если между интерфейсом и классом потенциально существует отношение совместимости, приведение может быть разрешено. Но окончательное решение принимается во время выполнения по реальному объекту.

interface Payment {}
class CardPayment implements Payment {}
class CashPayment implements Payment {}

Payment payment = new CardPayment();
CardPayment card = (CardPayment) payment; // успешно

Payment another = new CashPayment();
CardPayment wrong = (CardPayment) another; // ClassCastException

В первом случае объект действительно создан как CardPayment, хотя ссылка имеет тип Payment. Во втором случае фактический объект — CashPayment, поэтому он не может быть представлен как CardPayment.

Приведение к суперклассу или реализуемому интерфейсу обычно является расширяющим и безопасным: объект подкласса уже является экземпляром этого более общего типа. Обратное приведение является сужающим и требует проверки фактического типа.

Значимо, что приведение ссылки null не выбрасывает ClassCastException: результатом также будет null, поскольку объекта для проверки нет. Однако обращение к результату как к объекту позднее может привести к NullPointerException.

Если компилятор доказывает невозможность приведения, ошибка возникает ещё до запуска программы. Например, попытка привести экземпляр одного несвязанного финального класса к другому классу не имеет возможного корректного результата. Для интерфейсов анализ сложнее: не финальный класс теоретически может получить новую реализацию интерфейса, поэтому некоторые приведения компилятор оставляет для проверки во время выполнения.

Безопаснее сначала проверять тип через instanceof или использовать pattern matching, когда это доступно в целевой версии Java. Но сама проверка и последующее приведение должны опираться на одну и ту же логику; иначе между ними может появиться ошибка при изменении состояния или использовании многопоточности.

Ситуация из практики

Сервис получает список объектов типа Payment от разных модулей. Для карточных платежей требуется дополнительная операция, которой нет в интерфейсе. Разработчик без проверки приводит каждый платёж к CardPayment, но после подключения наличных платежей сервис начинает падать с ClassCastException.

Вариант с безусловным приведением прост и позволяет быстро вызвать специфичный метод, но он делает сервис зависимым от состава входных данных и ломается при появлении новой реализации. Вариант с проверкой типа предотвращает падение, однако может скрыть архитектурную проблему, если поддержка операции обязательна для всех платежей.

Лучшее решение — вынести требуемую операцию в отдельный интерфейс возможностей и проверять наличие этой возможности, а не зависеть от конкретного класса. Если операция действительно обязательна для каждого платежа, её следует включить в основной контракт Payment. Это снижает связанность, делает расширение системы предсказуемым и устраняет необоснованные приведения к реализации.

Что кандидаты часто упускают

Достаточно ли совпадения типа ссылки и целевого типа для успешного приведения?

Нет. Тип ссылки влияет на то, разрешит ли компилятор саму операцию и какие методы доступны до приведения, но не определяет фактический результат. Решение о совместимости принимает проверка объекта во время выполнения.

Например, две ссылки типа одного интерфейса могут указывать на разные реализации. Одна успешно приводится к конкретному классу, другая — нет, хотя статический тип у обеих ссылок одинаков.
Что произойдёт при приведении значения null к типу класса?

Приведение завершится успешно и даст значение null. ClassCastException не возникает, потому что проверка фактического класса объекта невозможна и не требуется: объекта нет.

Ошибка появится позже, если код попытается вызвать метод или обратиться к полю через полученную null-ссылку. Поэтому отсутствие исключения при приведении null не означает, что дальнейшая работа безопасна.
Почему приведение к интерфейсу иногда разрешается компилятором, хотя текущий класс его не реализует?

Если класс не объявлен как final, в Java потенциально может существовать его подкласс, реализующий этот интерфейс. Поэтому компилятор не всегда может доказать невозможность приведения и оставляет проверку на время выполнения.

Для финального класса или явно несовместимых типов компилятор может отвергнуть приведение сразу. Это различие отражает границу между статически доказуемой невозможностью и ситуацией, которую можно окончательно оценить только по фактическому объекту.