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

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

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

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

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

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

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

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

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

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

class Animal {
    func sound() { print("животное") }
}

class Dog: Animal {
    override func sound() { print("лай") }
}

func announce(_ animal: Animal) {
    animal.sound()
}

announce(Dog()) // лай

Здесь параметр функции статически имеет тип Animal, но объект является Dog, поэтому вызывается Dog.sound(). Это не означает, что через ссылку Animal доступны все методы Dog: доступный набор членов определяется статическим типом ссылки.

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

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

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

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

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

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

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

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

1. Меняется ли выбор метода, если ссылка на объект переназначается на другой экземпляр того же базового типа?

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

2. Чем переопределение метода отличается от перегрузки с точки зрения выбора вызова?

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

3. Что произойдёт, если метод объявлен как final в базовом классе?

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