При вызове переопределённого экземплярного метода через ссылку базового класса что определяет выбираемую ре...

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

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

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

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

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

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

В Java это привело бы к потере основного смысла переопределения: код, принимающий базовый тип, не мог бы использовать специализированное поведение подкласса. При этом нельзя переносить это правило на все элементы класса: перегрузка, статические методы и поля разрешаются иначе.

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

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

Например:

class Animal {
    void speak() { System.out.println("animal"); }
}

class Dog extends Animal {
    @Override
    void speak() { System.out.println("dog"); }
}

Animal animal = new Dog();
animal.speak(); // dog

Здесь ссылка имеет тип Animal, поэтому компилятор проверяет метод speak в Animal. Сам объект имеет класс Dog, поэтому во время выполнения вызывается переопределённый метод Dog.speak.

Это правило относится к обычным экземплярным методам, которые допускают переопределение. Статические методы не переопределяются, а скрываются: их выбор определяется типом ссылки. Приватные методы недоступны подклассу для переопределения, а final-методы запрещено переопределять.

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

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

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

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

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

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

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

1. Дополнительный вопрос: Что произойдёт, если метод в базовом классе перегружен, а в подклассе переопределена только одна сигнатура?

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

2. Дополнительный вопрос: Почему статический метод не демонстрирует полиморфизм при обращении через ссылку базового класса?

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

3. Дополнительный вопрос: Может ли вызов через базовый тип привести к методу, которого нет в базовом классе?

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