Скрытые возможности Objective-C

Позирует

Objective-C разрешает классу полностью заменить другой класс в приложении. Говорят, что замещающий класс «изображает» целевой класс. Все сообщения, отправленные целевому классу, вместо этого принимаются позирующим классом. Существуют некоторые ограничения на то, какие классы могут позировать:

• Класс может изображать только один из своих прямых или косвенных суперклассов.
• Позирующий класс не должен определять какие-либо новые переменные экземпляра, которые отсутствуют в целевом классе (хотя он может определять или переопределять методы).
• Никакие сообщения не должны быть отправлены целевому классу до позирования.

Позирование, как и категории, позволяет использовать глобальное расширение существующих классов. Постановка разрешает две функции, отсутствующие в категориях:

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

Пример:

@interface CustomNSApplication : NSApplication
@end

@implementation CustomNSApplication
- (void) setMainMenu: (NSMenu*) menu
{
     // do something with menu
}
@end

class_poseAs ([CustomNSApplication class], [NSApplication class]);

Это перехватывает каждый вызов setMainMenu для NSApplication.

Пересылка объекта / отсутствует метод

Когда объекту отправляется сообщение, для которого у него нет метод, исполняющая система дает ему еще один шанс обработать звонок перед тем, как отказаться. Если объект поддерживает -forward :: method, среда выполнения вызывает этот метод, передавая ему информация о необработанном звонке. Возвращаемое значение из переадресованный вызов возвращается к исходному вызывающему абоненту метод.

-(retval_t)forward:(SEL)sel :(arglist_t)args {
  if ([myDelegate respondsTo:sel])
 return [myDelegate performv:sel :args]
 else
 return [super forward:sel :args];
 }

Контент из Карманный справочник Objective-C

Это очень мощный инструмент, который активно используется сообществом Ruby для различных DSL, рельсов и т. д. Изначально он возник в Smalltalk, который повлиял как на Objective-C, так и на Ruby.

Метод Swizzling

По сути, во время выполнения вы можете заменить одну реализацию метода другой.

Вот объяснение с кодом.

Один из умных вариантов использования - это отложенная загрузка разделяемого ресурса: обычно вы реализуете метод sharedFoo, приобретая блокировку, создавая foo, если необходимо, получая его адрес, снимая блокировку, а затем возвращая foo. Это гарантирует, что foo создается только один раз, но каждый последующий доступ тратит время на блокировку, которая больше не нужна.

С помощью смены методов вы можете сделать то же самое, что и раньше, за исключением того, что после создания foo используйте swizzling для замены первоначальной реализации sharedFoo на вторую, которая не выполняет никаких проверок и просто возвращает foo, который, как мы теперь знаем, был создан. !

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

Справочник по среде выполнения Objective-C

Легко забыть, что синтаксический сахар Objective-C преобразуется в обычные вызовы функций C, которые являются средой выполнения Object-C. Скорее всего, вам никогда не придется вникать в что-либо и использовать что-либо во время выполнения. Вот почему я считаю это «скрытой функцией».

Позвольте мне указать способ использования системы времени выполнения.

Допустим, кто-то разрабатывает внешний API-интерфейс фреймворка, который будет использоваться третьими сторонами. И если кто-то разрабатывает класс в структуре, который абстрактно представляет пакет данных, мы назовем его MLAbstractDataPacket. Теперь дело за приложением, которое связывает во фреймворке подкласс MLAbstractDataPacket и определяет пакеты данных подкласса. Каждый подкласс должен переопределять метод +(BOOL)isMyKindOfDataPacket:(NSData *)data.

Имея в виду эту информацию ...

Было бы неплохо, если бы MLAbstractDataPacket предоставил удобный метод, возвращающий правильный инициализированный класс для пакета данных, который поступает в форме +(id)initWithDataPacket:(NSData *)data.

Здесь только одна проблема. Суперкласс не знает ни о одном из своих подклассов. Итак, здесь вы можете использовать метод среды выполнения objc_getClassList() вместе с objc_getSuperclass(), чтобы найти классы, которые являются подклассами MLAbstractDataPacket. Когда у вас есть список подклассов, вы можете затем пробовать +isMyKindOfDataPacket: на каждом, пока один из них не будет найден или не найден.

Справочную информацию об этом можно найти в http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html.

Категории

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

Приятно добавлять удобные методы к часто используемым классам, таким как NSString или NSData.

Мне нравится подробное именование методов, например [myArray writeToFile:myPath atomically:YES], где у каждого аргумента есть метка.

Переключение ISA

Нужно переопределить все поведение объекта? Фактически вы можете изменить класс активного объекта с помощью одной строчки кода:

obj->isa = [NewClass class];

Это изменяет только класс, который принимает вызовы методов для этого объекта; он не меняет расположение объекта в памяти. Таким образом, это действительно полезно только тогда, когда у вас есть набор классов с одинаковыми ivars (или один с подмножеством других), и вы хотите переключаться между ними.

Один фрагмент кода, который я написал, использует это для отложенной загрузки: он выделяет объект класса A, заполняет пару критических ivars (в данном случае в основном номер записи) и переключает указатель isa на LazyA. Когда вызывается любой метод, кроме очень маленького набора, такого как release и retain, LazyA загружает все данные с диска, завершает заполнение ivars, переключает указатель isa обратно на A и перенаправляет вызов реальному классу.