Какие типы диспетчеризации невозможно изменить с помощью Swizzling?

Типы диспетчеризации, недоступные для изменения через Swizzling

Swizzling — это техника в Objective-C и Swift (через Objective-C runtime), позволяющая подменить реализацию методов во время выполнения. Однако он работает только с определёнными типами диспетчеризации (dispatch), которые зависят от Objective-C runtime. Вот типы диспетчеризации, которые невозможно изменить с помощью Swizzling:

1. Статическая диспетчеризация (Static Dispatch)

Это прямое вызовов функций или методов, разрешаемое на этапе компиляции. Swizzling бессилен здесь, так как не участвует runtime.

• Пример в Swift:

struct Calculator {
    func add(_ a: Int, _ b: Int) -> Int {
        return a + b // Компилятор может встроить вызов (inline)
    }
}
let result = Calculator().add(2, 3) // Вызов разрешается статически

• Почему нельзя изменить: Swizzling опирается на динамические таблицы диспетчеризации Objective-C, а статические вызовы не используют их.

2. Диспетчеризация через виртуальные таблицы (V-Table Dispatch)

Используется для классов в Swift (не наследуемых от NSObject) и других языках. Методы хранятся в таблице, но она фиксирована после компиляции.

• Пример в Swift:

class Animal {
    func sound() { print("Some sound") }
}
class Dog: Animal {
    override func sound() { print("Bark") } // Размещается в V-Table
}

• Почему нельзя изменить: V-Table определяется компилятором и не модифицируется в runtime. Swizzling требует Objective-C runtime, который не управляет V-Table.

3. Директ-диспетчеризация (Direct Dispatch)

Частный случай статической диспетчеризации, где вызов метода компилируется в прямую инструкцию процессора.

• Пример: Финальные методы или методы в типах значений (struct, enum) в Swift.

final class FinalClass {
    func operation() { } // Direct dispatch
}

• Почему нельзя: Нет механизма перехвата вызова через runtime.

4. Диспетчеризация в чисто Swift-классах (без Objective-C)

Swift-классы, не помеченные как @objc или не наследующиеся от NSObject, используют V-Table или статическую диспетчеризацию.

• Пример:

class PureSwiftClass {
    func method() { }
}
// Swizzling невозможен, так как нет связи с Objective-C runtime.

5. Системные или сторонние функции на уровне C/C++

Вызовы функций из системных библиотек (например, libc) или скомпилированного C/C++ кода.

• Пример:

// C-функция
void cFunction() {
    printf("Hello from C\n");
}

• Почему нельзя: Они существуют вне Objective-C runtime.

6. Inline-функции и оптимизированные вызовы

Компилятор может оптимизировать вызовы, исключая диспетчеризацию вообще.

• Пример: Использование @inline(__always) в Swift.

@inline(__always) func helper() -> Int {
    return 42
}

Ключевое ограничение Swizzling

Swizzling работает только с динамической диспетчеризацией Objective-C (через objc_msgSend), которая использует таблицы методов (method tables). Для применения Swizzling метод должен быть частью Objective-C runtime:

• Классы должны наследоваться от NSObject (или быть аннотированы @objc в Swift).
• Методы должны быть помечены как dynamic (в Swift) или быть объявлены в Objective-C.

Пример работающего Swizzling в Objective-C:

// Original method
@implementation MyClass
- (void)originalMethod {
    NSLog(@"Original");
}
@end

// Swizzling
Method original = class_getInstanceMethod([MyClass class], @selector(originalMethod));
Method swizzled = class_getInstanceMethod([MyClass class], @selector(swizzledMethod));
method_exchangeImplementations(original, swizzled);

Заключение

Swizzling — мощный инструмент, но он ограничен динамической диспетчеризацией Objective-C. В современной iOS-разработке со смешанным кодом (Swift/Objective-C) важно понимать эти границы, чтобы избежать ошибок. Для Swift-кода предпочтительнее использовать протоколы, делегаты или модули для изменения поведения, а не полагаться на Swizzling.