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

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

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

Изначально переопределённый метод должен был возвращать точно такой же тип, как метод базового класса. Это ограничивало создание специализированных фабричных методов и fluent-интерфейсов: клиенту приходилось явно приводить результат к типу наследника.

В Java 5 появилась поддержка ковариантных возвращаемых типов. Она сохранила совместимость с контрактом базового класса и одновременно позволила наследнику возвращать более точный тип.

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

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

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

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

Ковариантность означает движение вниз по иерархии типов: если метод базового класса возвращает Объект, переопределение может возвращать Строка, поскольку Строка является подтипом Объект. Возврат суперкласса, несвязанного класса или примитивного типа вместо исходного ссылочного типа не считается корректным переопределением.

class Factory {
    Объект create() { return new Объект(); }
}

class StringFactory extends Factory {
    @Override
    Строка create() { return new Строка(); }
}

В примере вызов через ссылку типа Factory всё равно имеет статический результат Объект, потому что доступный тип определяется объявлением ссылки. Вызов через ссылку StringFactory получает тип Строка, поэтому приведение не требуется.

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

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

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

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

Рассматривались два варианта. Сохранить возвращаемый тип Документ было проще с точки зрения единого объявления, но требовало приведений типов у клиентов. Добавить отдельный метод с другим именем устраняло приведения, однако дублировало API и увеличивало риск расхождения поведения.

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

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

Считается ли метод переопределённым, если изменён только возвращаемый тип на несвязанный ссылочный тип?

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

Какой тип результата виден при вызове через ссылку базового класса?

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

Можно ли применить ковариантность к параметрам метода?

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