Что такое динамическая диспетчеризация в ООП?

Question

Что такое динамическая диспетчеризация в ООП?

Тип вопроса: ООП Вероятность: 22% Категория: IOS Разработчик

Ответ

Динамическая диспетчеризация — это механизм вызова метода, при котором конкретная реализация (из класса-наследника) определяется во время выполнения программы, а не на этапе компиляции. Это основа полиморфизма.

Как это работает в Swift:

Для классов используется таблица виртуальных методов (vtable).
Для протоколов — таблица свидетелей (witness table).

Пример:

class Vehicle {
    func move() { print("Vehicle moves") }
}

class Car: Vehicle {
    override func move() { print("Car drives") }
}

let myVehicle: Vehicle = Car() // Тип переменной - родительский
myVehicle.move() // Выведет "Car drives". Реализация выбрана в runtime.

Ключевые особенности:

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

Ответ 18+ 🔞

Да ты посмотри, какая хуйня интересная! Вот сидишь ты, пишешь свой код, и думаешь, что всё под контролем. А потом бац — и твой объект, который вроде как Vehicle, вдруг говорит, что он Car и едет по-другому. Это ж магия, блядь! Ну или не магия, а динамическая диспетчеризация, если по-умному.

Короче, представь ситуацию. У тебя есть общий тип, скажем, Vehicle. И есть конкретный тип — Car. Ты создаёшь объект Car, но записываешь его в переменную типа Vehicle. И вот когда ты вызываешь метод move(), система, ёпта, в самый последний момент, прямо во время работы программы (runtime, блядь!), соображает: «Ага, тут на самом деле не абстрактная телега, а конкретная тачка! Надо вызывать метод из Car!». Вот это и есть вся суть. Не на этапе компиляции решается, а прямо в бою.

class Vehicle {
    func move() { print("Vehicle moves") }
}

class Car: Vehicle {
    override func move() { print("Car drives") }
}

let myVehicle: Vehicle = Car() // С виду Vehicle, а внутри-то Car, хитрая жопа!
myVehicle.move() // А выведет-то "Car drives"! Вот тебе и динамика, блядь.

Как эта хуйня работает под капотом?

Для классов компилятор строит специальную таблицу — vtable (таблицу виртуальных методов). В ней для каждого класса лежат указатели на его настоящие методы. При вызове система лезет в эту таблицу и смотрит: «Ага, объект на самом деле вот этого класса, значит, метод брать вот отсюда». Небольшой overhead, но зато полиморфизм, блядь!
Для протоколов история похожая, но там своя таблица — witness table. Та же песня, только с другим акцентом.

Что важно помнить, чтобы не обосраться:

Это основа полиморфизма. Без этого мы бы не могли работать с кучей разных объектов через один интерфейс. Всё было бы статично и грустно.
За скорость надо платить. Поиск по таблице — это чуть дольше, чем прямой вызов. Не пиздец как медленно, но в сверхнагруженных кусках кода может быть заметно.
Можно помочь компилятору. Если ты знаешь, что класс или метод никогда не будет переопределён — пометь его как final. Компилятор вздохнёт с облегчением, скажет «спасибо, дружище» и выкинет всю эту динамику нахуй, сделав вызов статическим. Производительность подрастёт, всем хорошо. Экономия, блядь, на спичках, но иногда очень важная.

Вот и вся философия. Сначала кажется сложно, а потом привыкаешь и даже начинаешь этим пользоваться. Главное — понимать, когда эта динамика тебе нужна, а когда от неё можно и нужно избавиться ключевым словечком final.