Определение категорий для протоколов в Objective C?

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

Однако вы можете создать новый протокол, включающий старый, с объявление типа @protocol SpecialObject .

Я думаю, вы можете путать термины здесь и там. Расширения, категории, протоколы, интерфейсы и классы - все это разные вещи в Objective-C. В Язык Objective-C 2.0 Apple очень хорошо описывает различия, включая преимущества и недостатки использования категорий и расширений.

Если задуматься, что такое «Категория» или «Расширение». в концептуальном смысле? Это способ добавления функциональности к классу. В Objective-C протоколы не имеют реализации. Следовательно, как бы вы добавили или расширили реализацию того, что изначально не имеет реализации?

Краткий ответ: Нет.

Длинный ответ: как это будет работать? Представьте, что вы могли добавлять методы к существующим протоколам? Как это будет работать? Представьте, что мы хотим добавить еще один метод в NSCoding, скажем - (NSArray *) codingKeys; Этот метод является обязательным, который возвращает массив ключей, используемых для кодирования объекта.

Проблема в том, что существуют существующие классы (например, NSString), которые уже реализуют NSCoding, но не реализуют наш метод codingKeys . Что должно произойти? Как предварительно скомпилированный фреймворк узнает, что делать, когда это необходимое сообщение будет отправлено в класс, который его не реализует?

Вы могли бы сказать: «мы можем добавить определение этого метода через категорию. " или "

если вы уже пишете категорию, почему бы просто не добавить определение протокола в заголовок сразу после определения категории?

т.е.

@interface NSString (MyCategory)
- (BOOL) startsWith: (NSString*) prefix;
@end

@protocol MyExtendedProtocolName <NSString>
//Method declarations go here
@end

таким образом любой класс, который импортирует Заголовок категории также получит определение протокола, и вы можете добавить его в свой класс ..

@interface MyClass <OriginalProtocol,MyExtendedProtocolName>

также будьте осторожны при создании подкласса NSString, это кластер, и вы не всегда можете получить ожидаемое поведение.

Хотя верно, что вы не можете определять категории для протоколов (и не хотели бы, потому что вы ничего не знаете о существующем объекте), вы можете определить категории таким образом, чтобы код применялся только к объект данного типа, который имеет желаемый протокол (что-то вроде частичной специализации шаблона C ++).

Основное использование чего-то подобного - когда вы хотите определить категорию, которая зависит от настроенной версии класса. (Представьте, что у меня есть подклассы UIViewController, которые соответствуют протоколу Foo, то есть у них есть свойство foo, код моей категории может нуждаться в свойстве foo, но я не могу применить его к протоколу Foo, и если я просто применяю его для UIViewController код не компилируется по умолчанию, и принудительная его компиляция означает, что кто-то, занимающийся самоанализом или просто ошибся, может вызвать ваш код, который зависит от протокола. Гибридный подход может работать следующим образом:

@protocol Foo
- (void)fooMethod

@property (retain) NSString *foo;
@end

@implementation UIViewController (FooCategory)

- (void)fooMethod {
    if (![self conformsToProtocol:@protocol(Foo)]) {
        return;
    }

    UIViewController<Foo> *me = (UIViewController<Foo>*) self;
    // For the rest of the method, use "me" instead of "self"
    NSLog(@"My foo property is \"%@\"", me.foo);
}
@end

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