Cocoa plugin pattern

Question

У меня есть плагин для моего рабочего стола. Я реализовал его довольно стандартным образом, используя Apple's code loading guide.

У меня есть единственный протокол, который определяет все методы, на которые может или должен реагировать экземпляр плагина.

Единственная проблема заключается в том, что этот протокол определяет около 80 методов. Только около 10 из этих методов являются обязательными, а остальные являются необязательными. Некоторые плагины будут реализовывать все 80 методов, тогда как другие будут реализовывать только основные. 10.

Обычный способ для пакета плагинов рассказать своему хост-приложению, какой класс для создания экземпляра, через ключ NSPrincipalClass в файле Info.plist. Это единственный ключ, поэтому может быть создан только один класс.

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

Мой вопрос: какой лучший способ разделить функциональность внутри этого единственного протокола на несколько протоколов, в то же время позволяя разработчику плагина иметь более гибкую реализацию?

В настоящее время моих существующие плагины имеют следующий в своем основном классе:

- (BOOL)respondsToSelector:(SEL)selector { 
    return [self forwardingTargetForSelector:selector] ? YES : NO; 
} 

- (id)forwardingTargetForSelector:(SEL)selector { 
    id target = nil; 
    if ([self.instanceOne respondsToSelector:selector]) { 
     target = self.instanceOne; 
    } else if ([self.instanceTwo respondsToSelector:selector]) { 
     target = self.instanceTwo; 
    } else if ([self.instanceThree respondsToSelector:selector]) { 
     target = self.instanceThree; 
    } 

    return target; 
} 

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

Answer 1

Если вы можете разделить свои 80 методов на разумные куски функциональности, вы можете разделить их на несколько протоколов (FooProtcol, BarProtocol и т. Д.) И определить дополнительные свойства, которые возвращают ссылки на объекты, которые реализуют их в вашем основном протоколе. Например:

@protocol PluginPrimaryProtocol <NSObject> 
@required 
/* ... */ 
@optional 
@property (readonly) id<FooProtocol> fooDelegate; 
@property (readonly) id<BarProtocol> barDelegate; 
/* ... */ 
@end