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

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

Поэтому изменение фактического типа объекта само по себе не добавляет в вызов перегрузки, объявленные только в классе-потомке. Для их использования нужна ссылка подходящего типа или явное приведение.

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

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

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

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

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

Неверное ожидание динамического выбора перегрузки приводит к ошибке компиляции или к вызову другой сигнатуры, чем предполагал разработчик. Особенно опасны такие ошибки при передаче аргументов с типами интерфейсов, классов-родителей и null.

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

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

class Base {
    void send(Object value) { System.out.println("Base"); }
}

class Child extends Base {
    void send(String value) { System.out.println("String"); }
}

Base ref = new Child();
ref.send("text"); // Base

У ссылки ref статический тип Base, поэтому компилятор видит только send(Object). Фактический объект имеет тип Child, но send(String) не участвует в выборе перегрузки, поскольку эта сигнатура отсутствует в статическом типе ссылки.

Если бы в Child переопределили именно send(Object), после выбора этой сигнатуры JVM вызвала бы реализацию Child. Это ключевое различие: перегрузка выбирается статически, переопределение — динамически.

Статический тип аргументов также влияет на выбор перегрузки. Например, значение, фактически являющееся строкой, но сохранённое в переменной типа Object, при выборе перегрузки рассматривается как Object, если не выполнено явное приведение.

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

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

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

Рассматривались два варианта. Первый — повсеместно приводить Message к PaymentMessage: это даёт доступ к нужной перегрузке, но связывает обработчик с конкретным типом и создаёт риск исключения при неожиданном сообщении. Второй — оставить одну полиморфную операцию в базовом контракте и переопределять её в специализированных сообщениях: это лучше поддерживает расширение, но требует изменения общей модели обработки.

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

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

Вопрос: меняет ли явное приведение ссылки к типу подкласса набор доступных перегрузок?

Ответ: да. После приведения статический тип выражения становится типом подкласса, поэтому его перегрузки участвуют в компиляции вызова. Это не меняет фактический объект, а только даёт компилятору более узкое описание доступного интерфейса; если объект не является экземпляром этого типа, во время выполнения возможно ClassCastException.
Вопрос: какую роль играет тип аргумента при выборе перегруженного метода?

Ответ: компилятор учитывает статический тип каждого аргумента, применимость преобразований и правило выбора наиболее специфичной сигнатуры. Фактический тип объекта во время выполнения не заставляет JVM заново выбирать другую перегрузку. Поэтому переменная типа базового класса может привести к выбору перегрузки для базового типа, даже если фактический объект является экземпляром подкласса.
Вопрос: что произойдёт, если выбранная перегрузка переопределена в фактическом классе объекта?

Ответ: сначала компилятор фиксирует сигнатуру перегрузки, а затем для этой сигнатуры применяется динамическое связывание. Если метод является переопределяемым экземплярным методом, будет вызвана реализация фактического класса объекта; если метод static, он скрывается, а не переопределяется, и выбор определяется типом ссылки. Методы private также не участвуют в полиморфном переопределении.